GNOME Bugzilla – Bug 697397
Segfault when using page-up/page-down in dual mode or home/end in normal mode
Last modified: 2013-07-08 14:33:00 UTC
1. Open a PDF file with 4 or more pages. 2. Set Dual Mode 3. Press Page-Down, Page-Up, Page-Down 4. Segfault In gdb, sometimes I have to press 'Page-Up' once again to get the segfault. It seems like a thread issue (as in Bug #697194). I am not attaching any file because I can reproduce the bug with different PDF files that have 4 or more pages (I have not tried with smaller than 3, though). Here 2 stacktraces: First stacktrace: Starting program: /home/gpoo/code/evince/install/bin/evince interview-guadec.pdf [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1". [New Thread 0xb5669b40 (LWP 9148)] [New Thread 0xb4cffb40 (LWP 9149)] [New Thread 0xa7316b40 (LWP 9150)] [New Thread 0xa69ffb40 (LWP 9151)] Program received signal SIGSEGV, Segmentation fault. g_type_check_instance_is_a (type_instance=0xb7f0a130, iface_type=138301608) at gtype.c:3994 3994 check = node && node->is_instantiatable && iface && type_node_conforms_to_U (node, iface, TRUE, FALSE);
+ Trace 231742
It seems, this thing put both stacktraces as one. Here is the second one: Starting program: /home/gpoo/code/evince/install/bin/evince 'proposal.pdf' [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1". [New Thread 0xb5669b40 (LWP 9168)] [New Thread 0xb4cffb40 (LWP 9169)] [New Thread 0xa7316b40 (LWP 9170)] [New Thread 0xa69ffb40 (LWP 9171)] Program received signal SIGSEGV, Segmentation fault. g_list_prepend (list=0x87dc990, data=0x86dbe90) at glist.c:287 287 list->prev->next = new_list;
+ Trace 231743
*** Bug 698048 has been marked as a duplicate of this bug. ***
*** Bug 701040 has been marked as a duplicate of this bug. ***
I think this may be fixed by commit 068a358607bd634c53572c288b7e41514c172024; can anyone still repro on current master?
I have tested the version from master and the 3.9.2 and it seems that the segmentation fault from bug 701040 is fixed. Thank you can you please back-port it to evince 3.8.x releases?
(In reply to comment #4) > I think this may be fixed by commit 068a358607bd634c53572c288b7e41514c172024; > can anyone still repro on current master? I still can reproduce it with master. Here the output of bt full:
+ Trace 232023
I updated the summary because it normal mode it crashes as well, just using different keys. 1. Open a PDF file with 3 or more pages. 2. Press End, Home, End 3. Segfault The problem happens in ev_history_go_to_link when either history->priv->forward_list or history->priv->back_list is NULL. https://git.gnome.org/browse/evince/tree/shell/ev-history.c#n217 I am trying to understand what is the purpose of ev_history_go_to_link, returning FALSE immediately there does not seem to change the history behaviour.
Created attachment 246320 [details] Valgrind output It took out several lines regarding to cairo (which should be irrelevant to this bug).
*** Bug 701703 has been marked as a duplicate of this bug. ***
Pushed a fix to wip/history-fix branch. Rewiring the history was easier than trying to understand the logic in go_to_link, so I went that way. It's also conceptually easier now, IMHO.
FWIW, the new history fix the issue. Also I noticed that previously there were some cases where the history had saved a page more than once. For instance, after having browsed 2 pages (say Page 1, Page 4, Page 1), the widget still would have 'Back' enabled when it should not (it did not make any harm, just an extra click in the widget to get the button disabled). With the new implementation, this behaviour is also fixed.
*** Bug 702113 has been marked as a duplicate of this bug. ***
I am trying to reproduce a problem that the current fix is having. For reference, this the context: <KaL> chpe: another thing previous patch did, going to a page that is in the history (using the page entry or a link or whatever) should be like clicking in the history menu entry <KaL> not sure I explained it correctly <chpe> in go_to_link you mean? it should still do that. it searches in the list and sets it as current if found <gpoo> indeed, it should do that <KaL> hmm, let me try again <KaL> chpe: it doesn't happen here, do you have the hig document? I can tell you some steps to reproduce it <chpe> hmm just tried, seems I can get duplicate entries (ie page 2, page 2, page 1,...) in history. do you mean that? <chpe> let me see why that happens... <KaL> not exactly that <KaL> if you are in page X, clikc a link to go to page Y and then to page Z <KaL> when in Z the back list constains <KaL> X, Y <KaL> if you clik on X <KaL> the back list is empty <KaL> try the same but entering X in the page entry <KaL> back list is not empty and contains X in the middle of the list <KaL> I know my implementation was a mess, but the thing is complex :-) I tried to reproduce the problem as this: 1. Open a document (>4 pages) 2. Enable the sidebar (to navigate using the thumbnails) 3. Click on P4 in the thumbnails 3. Click on P3 in the thumbnails 4. Click on P1 in the thumbnails When using the history buttons, it will go only to P1 and P4, discarding P3 from the history. Another issue (more likely what Carlos meant): 1. Open PDF3200_2008.pdf (PDF specification from Adobe) 2. Open the index (sidebar) 3. Click on Comformance 4. Click on Syntax 5. Click on Comformance 6. Enter "i" in the entry box Now the history has i->iii->i The relevant comment on this from Christian: <chpe> the ev_history->priv->list contains 3 entries <chpe> item 0 and 2 are for page 'i' <chpe> but the link's action's EvLinkDest differ <chpe> because the 0th entry has page_label NULL, while the item 2 has page_label "i" <gpoo> oh, is it because they were triggered differently? <chpe> apparently the compare func is too strict <gpoo> it compares actions <gpoo> but this "problem" should be in master as well. <chpe> these actions are EV_LINK_ACTION_TYPE_GOTO_DEST, so it uses ev_link_dest_equal <chpe> the 0th item is EV_LINK_DEST_TYPE_PAGE, item 2 is EV_LINK_DEST_TYPE_PAGE_LABEL <chpe> so they differ <chpe> not sure how to fix this, but clearly a different problem than the corruption <chpe> looks like the corruption just 'hid' this, you'd crash before you could see the problem
For what it is worth, in master I do not see the problem with the history (duplicated entries), but after repeating the process several times, sometimes I get the following in console when I finish evince: (evince:12797): GLib-WARNING **: corrupted double-linked list detected (evince:12797): GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed The session only includes the step mentioned in c#13.
Should be fixed on master and 3-8. The history was also changed to be more 'web-browser like', ie we throw away the forward history on non-history navigation. That should also make the 'duplicate page' problem less annoying; if any other matters remain, please file new bugs. Thanks!
*** Bug 703491 has been marked as a duplicate of this bug. ***
*** Bug 703793 has been marked as a duplicate of this bug. ***