Description of problem: I received a template file with few fields to be filled and opened it with openoffice. Version-Release number of selected component (if applicable): openoffice.org-writer-2.0.4-5.5.10 How reproducible: I cannot reproduce it with few simple tests... I had some other files open as well. Expected results: Additional info: SELinux status: disabled ...end sestatus details ... ...start stackreport details ... 0x20ebf28: /usr/lib/openoffice.org2.0/program/libuno_sal.so.3 + 0x22f28 0x20ecbbb: /usr/lib/openoffice.org2.0/program/libuno_sal.so.3 + 0x23bbb 0xf84420: + 0x420 (__kernel_sigreturn + 0x0) 0x34efac1: /usr/lib/openoffice.org2.0/program/libsw680li.so + 0x98cac1 (SwWrtShell::StartInputFldDlg(SwField*, unsigned char, Window*, ByteString*) + 0xe1) 0x34efd32: /usr/lib/openoffice.org2.0/program/libsw680li.so + 0x98cd32 (SwWrtShell::UpdateInputFlds(SwInputFieldList*, unsigned char) + 0xe2) 0x330f253: /usr/lib/openoffice.org2.0/program/libsw680li.so + 0x7ac253 0x53c6488: /usr/lib/openoffice.org2.0/program/libsvl680li.so + 0xdf488 (SfxBroadcaster::Broadcast(SfxHint const&) + 0x48) 0x63ee0b8: /usr/lib/openoffice.org2.0/program/libsfx680li.so + 0x9c0b8 0x63ee168: /usr/lib/openoffice.org2.0/program/libsfx680li.so + 0x9c168 0x5a755ac: /usr/lib/openoffice.org2.0/program/libvcl680li.so + 0x9b5ac (Timer::Timeout() + 0x1c) 0x5a75799: /usr/lib/openoffice.org2.0/program/libvcl680li.so + 0x9b799 (Timer::ImplTimerCallbackProc() + 0x79) 0xe4614a: /usr/lib/openoffice.org2.0/program/libvclplug_gen680li.so + 0x4814a (X11SalData::Timeout() const + 0x2a) 0xc66ef6: /usr/lib/openoffice.org2.0/program/libvclplug_gtk680li.so + 0xfef6 0xc66f31: /usr/lib/openoffice.org2.0/program/libvclplug_gtk680li.so + 0xff31 0xa5fa16: /lib/libglib-2.0.so.0 + 0x2ba16 0xa5f442: /lib/libglib-2.0.so.0 + 0x2b442 (g_main_context_dispatch + 0x182) 0xa6241f: /lib/libglib-2.0.so.0 + 0x2e41f 0xa62985: /lib/libglib-2.0.so.0 + 0x2e985 (g_main_context_iteration + 0x65) 0xc68c31: /usr/lib/openoffice.org2.0/program/libvclplug_gtk680li.so + 0x11c31 0xe4f8a7: /usr/lib/openoffice.org2.0/program/libvclplug_gen680li.so + 0x518a7 (X11SalInstance::Yield(bool, bool) + 0x37) 0x5a6f618: /usr/lib/openoffice.org2.0/program/libvcl680li.so + 0x95618 (Application::Yield(bool) + 0x68) 0x5a6f6ec: /usr/lib/openoffice.org2.0/program/libvcl680li.so + 0x956ec (Application::Execute() + 0x3c) 0x5578359: /usr/lib/openoffice.org2.0/program/libsoffice.so + 0x26359 (desktop::Desktop::Main() + 0x1779) 0x5a751bc: /usr/lib/openoffice.org2.0/program/libvcl680li.so + 0x9b1bc 0x5a752c5: /usr/lib/openoffice.org2.0/program/libvcl680li.so + 0x9b2c5 (SVMain() + 0x35) 0x5569a69: /usr/lib/openoffice.org2.0/program/libsoffice.so + 0x17a69 (sal_main + 0x59) 0x5569af4: /usr/lib/openoffice.org2.0/program/libsoffice.so + 0x17af4 (main + 0x44) 0x33af2c: /lib/libc.so.6 + 0x15f2c (__libc_start_main + 0xdc) 0x80484a1: /usr/lib/openoffice.org2.0/program/swriter.bin + 0x4a1 ...end stackreport details ... ...start sample ldd details ... linux-gate.so.1 => (0x004a0000) libuno_sal.so.3 => /usr/lib/openoffice.org2.0/program/libuno_sal.so.3 (0x00110000) libuno_salhelpergcc3.so.3 => /usr/lib/openoffice.org2.0/program/libuno_salhelpergcc3.so.3 (0x006dd000) libstore.so.3 => /usr/lib/openoffice.org2.0/program/libstore.so.3 (0x0086d000) libdl.so.2 => /lib/libdl.so.2 (0x002d4000) libpthread.so.0 => /lib/libpthread.so.0 (0x0079a000) libstlport_gcc.so => /usr/lib/openoffice.org2.0/program/libstlport_gcc.so (0x00b10000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00e1a000) libm.so.6 => /lib/libm.so.6 (0x002d8000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00d6d000) libc.so.6 => /lib/libc.so.6 (0x00356000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x002ff000) /lib/ld-linux.so.2 (0x80000000) ...end sample ldd details ...
Can we get the sample document which appeared to trigger this attached ? SwWrtShell::StartInputFldDlg sounds indeed like this is related to clicking on an input field. caolanm->jnavrati: if we can get the document can you check clicking on the various input fields in the document and see if this can be reproduced. Also do a quick check of issuezilla at qa.openoffice.org to see if there are any similar stack traces of issues around "input fields" which might be relevant.
Created attachment 148789 [details] UT-KA.dot One of the files.
Created attachment 148790 [details] UT-KUEN.dot I had these two files opened at once.
caolanm->pawsa: There's a bit missing from the crash report, the top of the report had some details as to whether you were using GNOME or KDE, and if accessibility was enabled, so can you run... /usr/lib/openoffice.org2.0/program/crash_report -stack /tmp/notthere and attach the output of that so we can recover that missing info that might help us figure out how to reproduce.
My apologies: (I) x.org loaded video driver of... (II) Loading /usr/lib/xorg/modules/drivers/radeon_drv.so (II) Loading /usr/lib/xorg/modules/drivers/ati_drv.so (II) Reloading /usr/lib/xorg/modules/drivers/radeon_drv.so (III) Desktop is: GNOME (IV) libgcj version is: libgcj-4.1.1-51.fc6-i386 (V) kernel is: Linux 2.6.19-1.2911.fc6 #1 SMP Sat Feb 10 15:51:47 EST 2007 i686 athlon i386 (VI) OpenOffice.org core rpm version is: openoffice.org-core-2.0.4-5.5.10-i386 (VII) depth of root window: 24 planes (VIII) accessibility is: false (VIV) fedora release is: Fedora Core release 6 (Zod) ...start sestatus details ... SELinux status: disabled
ran it in valgrind, didn't see anything major yet, upstreamed a minor fix as http://www.openoffice.org/issues/show_bug.cgi?id=76132
got another more serious looking glitch with valgrind, might be the problem http://www.openoffice.org/issues/show_bug.cgi?id=76133. Will include these valgrind fixes in the next FC-6 update if there is one. Will be in the next rawhide/FC-7 build anyway. Would be awesome if there was a way to reproduce this so as to verify that these fixes actually solve this problem.
FWIW, I have not seen the bug ever since.
well, I've added the fixes that valgrind indicated might be relevant. We can reopen if we have data to show the problem remains.