Error without stacktrace when parsing long, complex document inside a Html comment tag
pietroppeter opened this issue · comments
I ran into a weird behaviour that I was able to minimize in the following example:
import markdown
let text = """
## title
some text:
- one point, and a [link](to_here)
- two points and **emphasis**
- three points, _really_?
+ sub point
+ another
""" # removing any single line or inline element (e.g. link, emphasis, ...) and error will disappear
var longText = "<!--\n" # if this is removed error disappears
for _ in 1 .. 30: # for less than 30 iterations, error disappears
longText &= text
longText.add "\n-->" # this can be removed and error will persist
echo markdown(longText)
Running this (nim 1.4.0, markdown #head) the program errors out without a stack trace.
If I reduce the number of iterations, or remove any line or element from text
the error disappears.
The behaviour seems to be related to the appearance of a long and fairly complex (from parsing perspective) text inside a Html coment tag (it is sufficient that it starts with <!--
).
Apart from this, I have to say this library is excellent, I have been using it extensively and it is the first time that it fails me (not too harmful, the workaround is simple: just split the text; it was only a bit tricky to minimize the error).
I take the opportunity to thank you for the work you did with nim-markdown and also nim-mustache, which are core dependencies of something I am working on and I am about to release (hopefully) soon: https://github.com/pietroppeter/nimib
Cool. Glad that the library I wrote becomes the building block of you library. I have been working on the other project recently and share little time on nim-markdown. I'll definitely take a look on the issue this weekend!
Yes, I guess those issues are probably related. Below some more remarks on my side, in case they are helpful.
I also did a test using WSL (the test above was on Windows) and I also had to raise iteration to 121 before failing. I was also able to see the segmentation fault error reported (on windows I did not see it).
Looking at this forum discussion, I was thinking maybe this is due to a stack overflow (most stuff is ref object so maybe the issue is too many calls to proc?). I did try to modify the stack size and test if iteration limit varies but I was not successful in this attempt:
- on windows I used
--passC="-Wl,--stack,16777216 "
but nothing seemed to change - on WSL I was not able to change stack size with
ulimit -S -s 16384
(there is WSL issue that should be fixed on WSL2 but it seems it is not - I am using WSL2)
Specific to this issue and related to performance (but really restricted only to specific case of Html Comments), looking at the source I notice the fact that an HTML comment could probably be dealt in a different way than other Markdown Blocks (parseHtmlComment
uses parseHTMLBlockContent
), since all its content does not need any further parsing (in particular in the above example the output is the same as the input).