Apache OpenOffice (AOO) Bugzilla – Issue 119346
Update check of a Java Extension causes constant crashes
Last modified: 2012-06-19 06:03:34 UTC
I guess this is where I log this... cant see anywhere else more appropriate, and its for 3.4 production which option is not offered. OO 3.4 crashes, often loading document and it just crashes out, sometimes it takes a cursor movement to do it, it constantly crashes, tried two documents, even crashed once when using options tools extensions.. machine was rebooted to ensure wasnt a mem issue, and with only OO running same things crash after crash after crash, highly annoying, did not occur under 3.3 will wait a couple days to se eif OO dev team has any suggestions else I'll revert to 3.3 Cant seem to find any crash report even though it asks if I want one in the recovery process *sigh* anyway the best I can get is with gdb... [New Thread 0xb2d68b70 (LWP 4213)] [Thread 0xb2d68b70 (LWP 4213) exited] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb3ac1b70 (LWP 4208)] 0x0572a80f in ?? () from /opt/openoffice.org3/program/../basis-link/program/deployment.uno.so (gdb) bt #0 0x0572a80f in ?? () from /opt/openoffice.org3/program/../basis-link/program/deployment.uno.so #1 0x05734cf4 in ?? () from /opt/openoffice.org3/program/../basis-link/program/deployment.uno.so #2 0x05735005 in ?? () from /opt/openoffice.org3/program/../basis-link/program/deployment.uno.so #3 0x0572e8a4 in ?? () from /opt/openoffice.org3/program/../basis-link/program/deployment.uno.so #4 0x05845528 in ?? () from /opt/openoffice.org3/program/../basis-link/program/updchk.uno.so #5 0x0583dcc4 in ?? () from /opt/openoffice.org3/program/../basis-link/program/updchk.uno.so #6 0x05840067 in ?? () from /opt/openoffice.org3/program/../basis-link/program/updchk.uno.so #7 0x0583e19f in ?? () from /opt/openoffice.org3/program/../basis-link/program/updchk.uno.so #8 0x00148075 in ?? () from /opt/openoffice.org3/program/../basis-link/ure-link/lib/libuno_sal.so.3 #9 0x0080b96e in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #10 0x0074498e in clone () from /lib/tls/i686/cmov/libc.so.6 (gdb)
The gdb backtrace is a good start. If you compiled AOO yourself or if you know how to compile individual libraries I suggest to recompile the directory main/desktop with build killobj ; build debug=t copy the resulting deployment.uno.so into /opt/openoffice.org3/basis-link/program/ and provide a new backtrace. Alternatively the only chance we have is to get the matching line from fgrep deployment.uno.so /proc/<pid>/maps with <pid> being the process id of "suffice.bin". To be sure also the md5sum of /opt/openoffice.org3/program/../basis-link/program/deployment.uno.so (the original one, not the one with debug-info) would be interesting.
*** Issue 119347 has been marked as a duplicate of this issue. ***
(In reply to comment #1) > The gdb backtrace is a good start. > > If you compiled AOO yourself or if you know how to compile individual > libraries I suggest to recompile the directory main/desktop with > build killobj ; build debug=t > copy the resulting deployment.uno.so into > /opt/openoffice.org3/basis-link/program/ and provide a new backtrace. > > Alternatively the only chance we have is to get the matching line from > fgrep deployment.uno.so /proc/<pid>/maps > with <pid> being the process id of "suffice.bin". To be sure also the md5sum > of /opt/openoffice.org3/program/../basis-link/program/deployment.uno.so > (the original one, not the one with debug-info) would be interesting. Firstly, no, this is from the AOO release (.deb binary package) fgrep deployment.uno.so /proc/4766/maps 02b94000-02c20000 r-xp 00000000 08:03 2934951 /opt/openoffice.org/basis3.4/program/deployment.uno.so 02c20000-02c26000 r--p 0008c000 08:03 2934951 /opt/openoffice.org/basis3.4/program/deployment.uno.so 02c26000-02c27000 rw-p 00092000 08:03 2934951 /opt/openoffice.org/basis3.4/program/deployment.uno.so If this is not enough I can download and build from source if need be, but due to pathetic ISP quotas, I cant before the 21st of this month. and... -r--r--r-- 1 root root 601584 2012-04-19 20:07 /opt/openoffice.org3/program/../basis-link/program/deployment.uno.so 22e12f029decd3310187c487ee30d12c /opt/openoffice.org3/program/../basis-link/program/deployment.uno.so
Another interesting data point would be, if you could disable the update check in Tools->Options->OpenOffice->OnlineUpdate Does it still crash? The debian package you downloaded seems to be for 32bit, right? The "fgrep deployment.uno.so /proc/<pid>/maps" and the backtrace should be from the same run, otherwise address space randomization (http://en.wikipedia.org/wiki/ASLR) does confuse us (here 0x0572a80f vs. 02b94000-02c27000). On the other hand if we'll have a backtrace with good debug symbols in deployment.uno.so in a few days it will certainly be worth the wait.
(In reply to comment #4) > Another interesting data point would be, if you could disable the update > check in > Tools->Options->OpenOffice->OnlineUpdate > Does it still crash? Interestingly, no, and this update has not worked in nearly 12 months, even a manual check immediately fails, so I guess its looking at the wrong place? > > The debian package you downloaded seems to be for 32bit, right? > That's correct, I have my SUSE system with 3.3 on it but its loaned to family member at present, so cant check the RPM version of 3.4 easily. > The "fgrep deployment.uno.so /proc/<pid>/maps" and the backtrace should be > from the same run, otherwise address space randomization > (http://en.wikipedia.org/wiki/ASLR) does confuse us (here 0x0572a80f vs. > 02b94000-02c27000). On the other hand if we'll have a backtrace with good > debug symbols in deployment.uno.so in a few days it will certainly be worth > the wait. Gotchya, I will be using it a bit again today so if it crashes out I'll grab that. so far, unable to get it to.
(In reply to comment #4) > Another interesting data point would be, if you could disable the update > check in > Tools->Options->OpenOffice->OnlineUpdate > Does it still crash? > > The debian package you downloaded seems to be for 32bit, right? > > The "fgrep deployment.uno.so /proc/<pid>/maps" and the backtrace should be > from the same run, otherwise address space randomization > (http://en.wikipedia.org/wiki/ASLR) does confuse us (here 0x0572a80f vs. > 02b94000-02c27000). On the other hand if we'll have a backtrace with good > debug symbols in deployment.uno.so in a few days it will certainly be worth > the wait. Do not know if this helps or is related to your initial suggestion, but clicking on update in the extensions options did cause it to crash, but NOT as yet in normal operation of using odt, or even odg files Program received signal SIGSEGV, Segmentation fault. 0x03e9d80f in ?? () from /opt/openoffice.org3/program/../basis-link/program/deployment.uno.so (gdb) bt #0 0x03e9d80f in ?? () from /opt/openoffice.org3/program/../basis-link/program/deployment.uno.so #1 0x03ea7cf4 in ?? () from /opt/openoffice.org3/program/../basis-link/program/deployment.uno.so #2 0x03ea8005 in ?? () from /opt/openoffice.org3/program/../basis-link/program/deployment.uno.so #3 0x03fc6e6b in ?? () from /opt/openoffice.org3/program/../basis-link/program/deploymentgui.uno.so #4 0x03fbde3a in ?? () from /opt/openoffice.org3/program/../basis-link/program/deploymentgui.uno.so #5 0x017ac66f in Control::ImplCallEventListenersAndHandler(unsigned long, Link const&, void*) () from /opt/openoffice.org3/program/../basis-link/program/libvcl.so #6 0x0179dd8e in Button::Click() () from /opt/openoffice.org3/program/../basis-link/program/libvcl.so #7 0x017a2c85 in PushButton::Tracking(TrackingEvent const&) () from /opt/openoffice.org3/program/../basis-link/program/libvcl.so #8 0x0198b5e1 in Window::EndTracking(unsigned short) () from /opt/openoffice.org3/program/../basis-link/program/libvcl.so #9 0x019a7f01 in ?? () from /opt/openoffice.org3/program/../basis-link/program/libvcl.so #10 0x019a94f1 in ?? () from /opt/openoffice.org3/program/../basis-link/program/libvcl.so #11 0x019a83fa in ?? () from /opt/openoffice.org3/program/../basis-link/program/libvcl.so #12 0x021fca3f in ?? () from /opt/openoffice.org/basis3.4/program/libvclplug_gtk.so #13 0x021f8fc1 in ?? () from /opt/openoffice.org/basis3.4/program/libvclplug_gtk.so #14 0x0258c434 in _gtk_marshal_BOOLEAN__BOXED (closure=0x81cd2d0, return_value=0xbfffeaa4, n_param_values=2, param_values=0x80e2db8, invocation_hint=0xbfffea90, marshal_data=0x21f8e0c) at /build/buildd/gtk+2.0-2.20.1/gtk/gtkmarshalers.c:84 #15 0x02342252 in IA__g_closure_invoke (closure=0x81cd2d0, return_value=0xbfffeaa4, n_param_values=2, param_values=0x80e2db8, invocation_hint=0xbfffea90) at /build/buildd/glib2.0-2.24.1/gobject/gclosure.c:767 #16 0x0235699d in signal_emit_unlocked_R (node=<value optimised out>, detail=<value optimised out>, instance=0x80b1048, emission_return=0xbfffebec, instance_and_params=0x80e2db8) at /build/buildd/glib2.0-2.24.1/gobject/gsignal.c:3248 #17 0x02357c33 in IA__g_signal_emit_valist (instance=0x80b1048, signal_id=34, detail=0, var_args=0xbfffec50 "|ìÿ¿\bY\b\bxìÿ¿ê\223k\002ôÿ\201\002H\020\v\b\230ìÿ¿H\020\v\bH\020\v\b\bY\b\b\230ìÿ¿") at /build/buildd/glib2.0-2.24.1/gobject/gsignal.c:2991 #18 0x02358256 in IA__g_signal_emit (instance=0x80b1048, signal_id=34, detail=0) at /build/buildd/glib2.0-2.24.1/gobject/gsignal.c:3038 #19 0x026b9646 in gtk_widget_event_internal (widget=<value optimised out>, event=0x807f860) at /build/buildd/gtk+2.0-2.20.1/gtk/gtkwidget.c:4951 #20 0x02584a6d in IA__gtk_propagate_event (widget=0x80b1048, event=0x807f860) at /build/buildd/gtk+2.0-2.20.1/gtk/gtkmain.c:2447 #21 0x02585e17 in IA__gtk_main_do_event (event=0x807f860) at /build/buildd/gtk+2.0-2.20.1/gtk/gtkmain.c:1647 #22 0x0287a39a in gdk_event_dispatch (source=0x8082418, callback=0, user_data=0x0) ---Type <return> to continue, or q <return> to quit--- at /build/buildd/gtk+2.0-2.20.1/gdk/x11/gdkevents-x11.c:2372 #23 0x023c05e5 in g_main_dispatch (context=0x8082460) at /build/buildd/glib2.0-2.24.1/glib/gmain.c:1960 #24 IA__g_main_context_dispatch (context=0x8082460) at /build/buildd/glib2.0-2.24.1/glib/gmain.c:2513 #25 0x023c42d8 in g_main_context_iterate (context=0x8082460, block=<value optimised out>, dispatch=1, self=0x8057e58) at /build/buildd/glib2.0-2.24.1/glib/gmain.c:2591 #26 0x023c44b8 in IA__g_main_context_iteration (context=0x8082460, may_block=1) at /build/buildd/glib2.0-2.24.1/glib/gmain.c:2654 #27 0x021e6ac4 in ?? () from /opt/openoffice.org/basis3.4/program/libvclplug_gtk.so #28 0x02240e9d in X11SalInstance::Yield(bool, bool) () from /opt/openoffice.org/basis3.4/program/libvclplug_gen.so #29 0x0178fd14 in ?? () from /opt/openoffice.org3/program/../basis-link/program/libvcl.so #30 0x0178f272 in Application::Yield(bool) () from /opt/openoffice.org3/program/../basis-link/program/libvcl.so #31 0x0178f2a3 in Application::Execute() () from /opt/openoffice.org3/program/../basis-link/program/libvcl.so #32 0x003045eb in ?? () from /opt/openoffice.org3/program/../basis-link/program/libsofficeapp.so #33 0x0179321c in ?? () from /opt/openoffice.org3/program/../basis-link/program/libvcl.so #34 0x017933b3 in SVMain() () from /opt/openoffice.org3/program/../basis-link/program/libvcl.so #35 0x0031e668 in soffice_main () from /opt/openoffice.org3/program/../basis-link/program/libsofficeapp.so #36 0x08048d14 in main () 03e79000-03f05000 r-xp 00000000 08:03 2934951 /opt/openoffice.org/basis3.4/program/deployment.uno.so 03f05000-03f0b000 r--p 0008c000 08:03 2934951 /opt/openoffice.org/basis3.4/program/deployment.uno.so 03f0b000-03f0c000 rw-p 00092000 08:03 2934951 /opt/openoffice.org/basis3.4/program/deployment.uno.so
Ok, so getting the update status of one of the extensions causes the problem. It would be interesting to know which of the extensions causes this. Having deployment.uno.so with debug info would help a lot, not only to get the method names and line numbers, but also for their arguments and locals vars.
*** Issue 119362 has been marked as a duplicate of this issue. ***
This bug is for some specific extension update, not common problem, do not think it is AOO 3.4.1 candidate.
Change the version to AOO350
zhao xia: I am a little bit confused. On the one hand you say that you think that this issue is _not_ a candidate for AOO 3.4.1. On the other hand you have set the 3.4.1_release_blocker flag to ?, changed its priority from P3 to P1. Can you please clarify the situation? BTW, the purpose of field version is to indicate the application version in which the defect occurs. Thus, I reset it back to AOO340
I saw that the "confirmed" flag was now set, which means that someone could reproduce the problem independently and on different system from where it was originally reported. If that is the case does this new system also no longer crash when Tools->Options->OpenOffice->OnlineUpdate gets disabled? Also it would help even more, if one of the systems could provide a backtrace when debug info was compiled into the relevant libraries.
Oliver, removed the release blocker flag.Change the priority is to identfy the important to AOO 3.5
The 'version' entry describes in which AOO version the bug has been found. It can't be AOO350 as it is not released yet. From my understanding this is not a common AOO behavior but related to a special extension. So it can't be a P1 issue. Normally a crash is a P2.
I think It is necessary to know which of the extensions causes this. I can't reproduce crash when update check of some embedded extensions on Redhat with AOO3.4 release version.
Updated Java and it did not crash for a longer time so java update helped i think
This probably means that a Java based extension was responsible for the update problems. Updated the summary line and the issue status.
Apache worked for about 2 hours after the java update, then it resumed the constat crashes I noticed there are 2 language extensions, french and spanish, that won't accept management, could not delete them, wondered if they could be involved.
Verified it on Aoo_Trunk_20120616.1800.1350879 and it does not reproduce, so close it as fixed.