Also, please provide a test so that we can check that the bug is solved.
I'm not sure how this test can fit in the test suite (I'm not sure about
checking things like stack overflows or bad performance in general
because it depends on the machine), but at least a sequence of commands
that permit us reproduce the bug and see that your patch solves it.
2 patches for repository http://darcs.net/screened:
Sat Jun 15 16:53:30 ART 2013 Jose Luis Neder <jlneder@gmail.com>
* resolve issue2313: whatsnew -l: Stack space overflow
Mon Jun 17 12:31:42 ART 2013 Jose Luis Neder <jlneder@gmail.com>
* tests for issue2313: whatsnew -l: Stack space overflow
I added the test to the test suite. The issue happens when there isn't
a trailing newline in a new text file. Then when the bytestring go to the
function "diff_to_empty" it discriminate between a file ending in newline and
one that doesn't because it has to add an B.empty (aka. "") bytestring to
compare if it not end in a new line to get the patch right. But then it send
the lines to the function "canonizeHunk" that discriminates between an "empty
to something" or "something to empty" patch and other kind of modification
and tries to shrink the patch with the function "getChanges" then go
"getChanges'" and then it looks for collisions and make a mess creating
a lots of maps with mkAMap and if the file it's big enough or have enough
number of lines it ends in a stack overflow. But in the function
"canonizeHunk", it shouldn't discriminate a file that not end in a newline
differently than a file that is. That's why if you change canonizeHunk to add
this case it create a patch instantly without any more hassle. The test only
make a file with enough lines for my machine to get a stack overflow without
the bugfix. I think it is enough for any machine but i'm only speculating. If
it doesn't overflow on your machine only make a larger file changing the 18
number to 19 or 20 in the file:
"tests/issue2313-trailing-newlines-stack-overflow.sh".