GNOME Bugzilla – Bug 358142
crash in Document Viewer: Starting instances of ev...
Last modified: 2006-11-26 17:48:37 UTC
Version: 0.6.0 What were you doing when the application crashed? Starting instances of evince to preview documents from within LyX. I also see: ** (evince:20672): WARNING **: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. *** glibc detected *** evince: double free or corruption (out): 0xb392ca28 *** Distribution: Ubuntu 6.10 (edgy) Gnome Release: 2.16.0 2006-09-04 (Ubuntu) BugBuddy Version: 2.16.0 Memory status: size: 79134720 vsize: 0 resident: 79134720 share: 0 rss: 19685376 rss_rlim: 0 CPU usage: start_time: 1159456729 rtime: 0 utime: 86 stime: 0 cutime:79 cstime: 0 timeout: 7 it_real_value: 0 frequency: 0 Backtrace was generated from '/usr/bin/evince' (no debugging symbols found) Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread -1229220176 (LWP 20637)] [New Thread -1230443616 (LWP 20658)] 0xffffe410 in __kernel_vsyscall ()
+ Trace 73475
Thread 2 (Thread -1230443616 (LWP 20658))
Thanks for the bug report. Unfortunately, that stack trace is not very useful in determining the cause of the crash. Can you get us one with debugging symbols? Please see http://live.gnome.org/GettingTraces for more information on how to do so.
You are kind to thank me for such a lousy bug report. I must admit, I wouldn't have filed it without looking into the problem further, but then bugbuddy popped up, and I chose the easy way out.. :^) I'd be glad if I could get a developer to reproduce the bug reliably. Unfortunately, that might not be so easy -- I'm not exactly sure how to do it myself. The best way thus far seem to be: 1. Load a certain DVI file generated by LyX (it doesn't break on all). 2. Type "Ctrl-R" to refresh and wait while evince breaks. I'm afraid that, in order to give you a better traceback, I'll have to recompile evince with debugging options. I gather this (maybe incorrectly) from looking at the valgrind output: ==3051== Invalid read of size 4 ==3051== at 0x809FAA1: (within /usr/bin/evince) ==3051== by 0x809E21F: (within /usr/bin/evince) ==3051== by 0x809E602: (within /usr/bin/evince) ==3051== by 0x809DC50: (within /usr/bin/evince) ==3051== by 0x809AE9C: (within /usr/bin/evince) ==3051== by 0x809A6B1: (within /usr/bin/evince) ==3051== by 0x808B36F: (within /usr/bin/evince) ==3051== by 0x805E90B: (within /usr/bin/evince) ==3051== by 0x805D468: (within /usr/bin/evince) ==3051== by 0x805D9DB: (within /usr/bin/evince) ==3051== by 0x4B0B41E: g_thread_create_proxy (gthread.c:553) ==3051== by 0x4D97503: start_thread (in /lib/tls/i686/cmov/libpthread-2.4.so) ==3051== Address 0x7957820 is 7,000 bytes inside a block of size 21,420 free'd ==3051== at 0x4020EF1: free (vg_replace_malloc.c:233) ==3051== by 0x80A64B5: (within /usr/bin/evince) ==3051== by 0x809F29A: (within /usr/bin/evince) ==3051== by 0x809CA2A: (within /usr/bin/evince) ==3051== by 0x809AC4E: (within /usr/bin/evince) ==3051== by 0x4A33B8B: g_object_unref (gobject.c:1785) ==3051== by 0x806A6D2: (within /usr/bin/evince) ==3051== by 0x8072A83: (within /usr/bin/evince) ==3051== by 0x4A3EBD8: g_cclosure_marshal_VOID__VOID (gmarshal.c:77) ==3051== by 0x4A3183A: g_closure_invoke (gclosure.c:490) ==3051== by 0x4A41C42: signal_emit_unlocked_R (gsignal.c:2438) ==3051== by 0x4A43166: g_signal_emit_valist (gsignal.c:2197)
Oh, great backtrace, thanks. Btw, Stefan, can you attach that dvi document?
Created attachment 73795 [details] Bane of evince
Should be fixed in recent HEAD. *** This bug has been marked as a duplicate of 374277 ***