Bug 161319
Summary: | [x86_64] ATI Radeon 8500 (double free ?) ooffice SEGV during startup | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Jan "Yenya" Kasprzak <kas> |
Component: | openoffice.org | Assignee: | Caolan McNamara <caolanm> |
Status: | CLOSED WORKSFORME | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 4 | CC: | caolanm, jcucurull |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2005-07-14 09:46:30 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Jan "Yenya" Kasprzak
2005-06-22 12:36:20 UTC
I wonder if bug 160770 is relevent I don't think so - I don't have LD_LIBRARY_PATH set, and I have different symptoms (SIGSEGV instead of unresolved symbols). Also "ldd soffice.bin" returns /lib/libpthread.so.0 instead of /lib/obsolete/.../libpthread.so.0. Oops, I meant I don't have LD_ASSUME_KERNEL set (altough I don't have LD_LIBRARY_PATH set either). Can you try the 1.9.112 update and see if this persists. The unusual thing about your architecture is that it's 64bit while OOO is 32bit. If the problem persists, do any other 32bit apps crash, or does SELINUX settings matter. i.e. setenforce It is the same with 1.9.112. I have "SELINUX=disabled" in /etc/sysconfig/selinux. I have tried /bin/ls and /bin/bash from 32-bit system (after installing missing libraries - libtermcap.i386, libacl.i386, and libattr.i386), and both ls and bash seem to work OK. ah ls and bash are only mickey mouse applications, something like firefox is what I have in mind :-) OK, I've tried firefox.i386 (and removed firefox.x86_64), and it works. Hmm, I've tried to run ooffice from my x86_64 box remotely with display on another box (FC4-i386, FWIW), and it worked. So the problem is probably in local display only. I ran into the same problem and eventually discovered that a double free issue when ooffice was run with the x86_64 ATi 8500 Xserver. The work-around was to do: export MALLOC_CHECK_=1 and then run ooffice from the same command line. caolanm->mharris: think this is something xorg-x11 ATI Radeon 8500 specific ? Use strace/ltrace/gdb, to further diagnose the root cause. There doesn't seem to be any X libraries implicated above, but if further diagnosis leads to the conslusion of a specific bug in an X library, please ping the xgl-maint team again and we'll review the issue again with more complete details. You may also find testing with the "vesa" driver, or disabling DRI and/or accel to be useful in diagnosing the problem. If there are any differences, it could help narrow down the problem domain. Hope this helps. I have the same problem, but I'm using Fedora Core 4 on 32 bits version over a Pentium-M with an Intel 852 graphics card. When I started fedora for first time it run ok, but later since I've updated all packets, openoffice leave to work presenting the same error described in this post. What I really need is some information to be able to track this down. If someone is brave enough to install the large debuginfo package for OOo and run gdb /usr/lib/openoffice.org2.0/program/soffice.bin (gdb) run -writer and on crash (gdb) bt It might be helpful to find the problem Hi Caolan, I'll installed debug info package and I've followed your instructions. These are the results: GNU gdb Red Hat Linux (6.3.0.0-1.21rh) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1". (gdb) run -writer Starting program: /usr/lib/openoffice.org2.0/program/soffice.bin -writer Reading symbols from shared object read from target memory...done. Loaded system supplied DSO at 0xeba000 [Thread debugging using libthread_db enabled] [New Thread -1209121088 (LWP 5263)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1209121088 (LWP 5263)] 0x00a5bca1 in _dl_map_object_from_fd () from /lib/ld-linux.so.2 (gdb) bt #0 0x00a5bca1 in _dl_map_object_from_fd () from /lib/ld-linux.so.2 #1 0x00a5e355 in _dl_map_object () from /lib/ld-linux.so.2 #2 0x00a66ff4 in dl_open_worker () from /lib/ld-linux.so.2 #3 0x00a63a10 in _dl_catch_error () from /lib/ld-linux.so.2 #4 0x00a67742 in _dl_open () from /lib/ld-linux.so.2 #5 0x00bc6d42 in dlopen_doit () from /lib/libdl.so.2 #6 0x00a63a10 in _dl_catch_error () from /lib/ld-linux.so.2 #7 0x00bc73fa in _dlerror_run () from /lib/libdl.so.2 #8 0x00bc6dd2 in dlopen@@GLIBC_2.1 () from /lib/libdl.so.2 #9 0x053a6482 in __glPointParameteriv_size () from /usr/X11R6/lib/libGL.so.1 #10 0x053a677b in driGetDriver () from /usr/X11R6/lib/libGL.so.1 #11 0x053a69e8 in driCreateDisplay () from /usr/X11R6/lib/libGL.so.1 #12 0x053c670c in __glXInitialize () from /usr/X11R6/lib/libGL.so.1 #13 0x053c2364 in __indirect_glCompressedTexSubImage1D () from /usr/X11R6/lib/libGL.so.1 #14 0x053c2ca0 in glXGetConfig () from /usr/X11R6/lib/libGL.so.1 #15 0x011d9e14 in X11SalOpenGL::MakeVisualWeights (pDisplay=0x9c9d420, pInfos=0x9cb03f0, pWeights=0xbfc02dd0, nVisuals=8) at /usr/src/debug/SRC680_m112/vcl/unx/source/gdi/salogl.cxx:420 #16 0x011f3504 in SalDisplay::BestVisual (pDisplay=0x9c9d420, nScreen=0, rVI=@0xbfc02e84) at /usr/src/debug/SRC680_m112/vcl/unx/source/app/saldisp.cxx:563 #17 0x0089ab8d in GtkXLib::Init (this=0x2c2e20) at /usr/src/debug/SRC680_m112/vcl/unx/gtk/app/gtkdata.cxx:547 #18 0x0089af7c in GtkData::Init (this=0x704f01c) at /usr/src/debug/SRC680_m112/vcl/unx/gtk/app/gtkdata.cxx:866 #19 0x0089bd73 in create_SalInstance (pModule=0x9c87c20) at /usr/src/debug/SRC680_m112/vcl/unx/gtk/app/gtkinst.cxx:214 #20 0x03767af9 in tryInstance (rModuleBase=Variable "rModuleBase" is not available. ) at /usr/src/debug/SRC680_m112/vcl/unx/source/plugadapt/salplug.cxx:116 #21 0x03767bf9 in CreateSalInstance () at /usr/src/debug/SRC680_m112/vcl/unx/source/plugadapt/salplug.cxx:465 #22 0x035d2aef in InitVCL (rSMgr=@0xbfc02fd0) at /usr/src/debug/SRC680_m112/vcl/source/app/svmain.cxx:334 #23 0x035d2c5b in SVMain () at /usr/src/debug/SRC680_m112/vcl/source/app/svmain.cxx:261 #24 0x080618cb in sal_main (argc=2, argv=0xbfc030b4) at /usr/src/debug/SRC680_m112/desktop/source/app/main.cxx:103 #25 0x00a88de6 in __libc_start_main () from /lib/libc.so.6 #26 0x08061801 in _start () (gdb) excellent work jordi, but in your case the relevent stuff appears to be... #9 0x053a6482 in __glPointParameteriv_size () from /usr/X11R6/lib/libGL.so.1 #10 0x053a677b in driGetDriver () from /usr/X11R6/lib/libGL.so.1 #11 0x053a69e8 in driCreateDisplay () from /usr/X11R6/lib/libGL.so.1 #12 0x053c670c in __glXInitialize () from /usr/X11R6/lib/libGL.so.1 #13 0x053c2364 in __indirect_glCompressedTexSubImage1D () from /usr/X11R6/lib/libGL.so.1 #14 0x053c2ca0 in glXGetConfig () from /usr/X11R6/lib/libGL.so.1 #15 0x011d9e14 in X11SalOpenGL::MakeVisualWeights (pDisplay=0x9c9d420, pInfos=0x9cb03f0, pWeights=0xbfc02dd0, nVisuals=8) at /usr/src/debug/SRC680_m112/vcl/unx/source/gdi/salogl.cxx:420 A) I have a test program attached to bug 139712 (source at https://bugzilla.redhat.com/beta/attachment.cgi?id=108799 use gcc testgl.c -o testgl -L/usr/X11R6/lib -lX11 -lGL to compile) / (precompiled binary at https://bugzilla.redhat.com/beta/attachment.cgi?id=108798). Can you run it and paste the output in here also, basically I expect it to crash the same as OOo does above. B) as a workaround does export SAL_NOOPENGL=true from the shell you launch OOo from make it not crash ? I expect it to not crash in this case. If A & B fit expectations I don't think it's the same as the original bug submitters problem, as SAL_NOOPENGL didn't do anything for him, if I'm right then you should write a seperate bug against xorg with the demo program above attached as "how to reproduce" Hi Caolan, I've tested your program. The result is a segment fault, and with the debuger, doing the same that with OpenOffice, the result is: (gdb) run Starting program: /home/jordicj/Proves/testgl Reading symbols from shared object read from target memory...(no debugging symbo ls found)...done. Loaded system supplied DSO at 0x9f7000 (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread -1208219168 (LWP 5784)] (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1208219168 (LWP 5784)] 0x00a5bca1 in _dl_map_object_from_fd () from /lib/ld-linux.so.2 (gdb) bt #0 0x00a5bca1 in _dl_map_object_from_fd () from /lib/ld-linux.so.2 #1 0x00a5e355 in _dl_map_object () from /lib/ld-linux.so.2 #2 0x00a66ff4 in dl_open_worker () from /lib/ld-linux.so.2 #3 0x00a63a10 in _dl_catch_error () from /lib/ld-linux.so.2 #4 0x00a67742 in _dl_open () from /lib/ld-linux.so.2 #5 0x00bc6d42 in dlopen_doit () from /lib/libdl.so.2 #6 0x00a63a10 in _dl_catch_error () from /lib/ld-linux.so.2 #7 0x00bc73fa in _dlerror_run () from /lib/libdl.so.2 #8 0x00bc6dd2 in dlopen@@GLIBC_2.1 () from /lib/libdl.so.2 #9 0x0013e482 in __glPointParameteriv_size () from /usr/X11R6/lib/libGL.so.1 #10 0x0013e77b in driGetDriver () from /usr/X11R6/lib/libGL.so.1 #11 0x0013e9e8 in driCreateDisplay () from /usr/X11R6/lib/libGL.so.1 #12 0x0015e70c in __glXInitialize () from /usr/X11R6/lib/libGL.so.1 #13 0x0015a364 in __indirect_glCompressedTexSubImage1D () from /usr/X11R6/lib/libGL.so.1 #14 0x0015aca0 in glXGetConfig () from /usr/X11R6/lib/libGL.so.1 #15 0x0804861a in main () (gdb) And effectively, exporting SAL_NOOPENGL=true OpenOffice works well. I'll submit this bug to Xorg. Thanks for your help. OOo works for me, I don't have one of these cards myself to find out myself what the problem is, though I suspect whatever it is, it's not OOo specific. (In reply to comment #17) > OOo works for me, I don't have one of these cards myself to find out myself what > the problem is, though I suspect whatever it is, it's not OOo specific. In my case definitely it's not a an OpenOffice problem, because I'd experienced the same Segmentation Fault with "glxgears" and "glxinfo". I've posted the problem on X.org, but for the moment it hasn't responded me. A curious thing is that before apply any updates to my FC4, I hadn't this problem. I've waiting for a new X.org update that miraculously solves my problem. Thanks for your help. Yesterday my problem was solved with the new Xorg updates (xorg-x11-6.8.2-37.FC4.45.i386). |