Bug 15606

Created attachment 16045 [details] [review]
Pass the right y to TextLine::visitSelection when x are the same

I had a look at the code with the debugger and the problem why the segfault occurs is that in line 3778 of poppler/TextOutputDev.cc the TextWord *begin is NULL.

The code which searches the begin word seems to be correct, but the selection which was passed to TextLine::visitSelection doesn't actually "touch" a word in the line, because its y is bigger than yMax of any of the words. So the problem maybe lies somewhere in the calculation of the child_selections in the calling functions. Here are the selection parameters in the various functions:

TextPage::visitSelection: {x1 = 155.8125, y1 = 610.875, x2 = 155.8125, y2 = 616.5}
TextBlock::visitSelection: {x1 = 155.8125, y1 = 610.875, x2 = 155.8125, y2 = 616.5}
TextLine::visitSelection: {x1 = 155.8125, y1 = 616.5, x2 = 612, y2 = 792}

The two x are the same, but somehow the bigger y is passed to TextLine::visitSelection. The attached patch fixes this and makes my original test case work. There's another problem though.

Here's another way to trigger the same segfault again, using the same document on the same page:

1. Download the PDF version of the document at http://research.sun.com/techrep/1996/abstract-52.html
2. Open it in Evince and navigate to page 66 of the PDF
3. Position the cursor between the word "connects" in the sentence "The algorithm connects the send to all k templates" and the rho letter (ρ) beneath its second "n".
4. Double-click
5. Crash

Here's the line of the segfault, the backtrace is the same as with the first test case:

Program received signal SIGSEGV, Segmentation fault.
TextLine::visitSelection (this=0xd06340, visitor=0x7fff24d3f910, selection=0x7fff24d3f800, style=selectionStyleWord) at TextOutputDev.cc:3778
3778	    child_selection.x1 = begin->xMin;

Here are the selection parameters:

TextPage::visitSelection: {x1 = 223.3125, y1 = 617.0625, x2 = 223.3125, y2 = 617.0625}
TextBlock::visitSelection: {x1 = 223.3125, y1 = 617.0625, x2 = 223.3125, y2 = 617.0625}
TextLine::visitSelection: {x1 = 223.3125, y1 = 617.0625, x2 = 612, y2 = 792}

This time, the y is too big from the start. I don't know the code, but there's something wrong in the calculation of the child_selections or the lines which should be visited...

hmm, it still crashes for me after applying the patch . . . 

I just did a rough count of the duplicates of this bug over at the gnome bug tracker. It has been reported about 33 times! Here are the two bug reports with the duplicates:

http://bugzilla.gnome.org/show_bug.cgi?id=501673
http://bugzilla.gnome.org/show_bug.cgi?id=528484

So, I think raising the severity of this bug to "major" is justified.

Can someone who knows the code a bit (or preferably the one who wrote it) go over the selection code and try to find the cause of this bug? It may be something simple like an "and" where an "or" should be or a one off error.

Created attachment 20409 [details] [review]
proposed patch

Hi,
this is caused by different sizes of bounding boxes of words and bounding boxes
of lines.
This can happen for a special character in a line. Height of the bounding box
of such line is then higher than bounding boxes of normal words.
If user double clicks in the space inside bounding box of such a line, but
outside bounding box of the closest word, then the application crashes.
(it crashes after searching for the beginning of the selection, because
beginning word is not hit but it is supposed that it was hit)
The attached patch avoids crashing by simple cancellation of such a selection.

  Regards

    Marek


How to reproduce:
1) Open a document in Evince (zoom 400%).
2) Find a line with a special character (lower index, for example).
3) Double click to space between this line and the line below this one (not close to the word containing the special character). - try this several times with different vertical positions between those lines

I've just applied a slightly different patch. Could you confirm the problem is actually fixed, please? If the problem is fixed I'll backport it to the stable branch. 

Thanks. 

Hi Carlos,
the bug doesn't occur any more. So, it is fixed.
(I tested it with the line described in http://bugzilla.gnome.org/show_bug.cgi?id=528484)

    Marek

The fix is in poppler-0.10 branch too. 

Thank you all for your help.