12:36 p.m.
I reported a crash to the idSoftware folks that appears to be a Fedora
x86_64 specific libGL crash.
I'm not really able to provide much in the way of debugging traces other
than show that a crash is occuring in libGL. According to id, x86_64
Fedora is the only distro reporting this crash:
Core was generated by `./etqw.x86 +set developer 1 +set logfile 1'.
Program terminated with signal 11, Segmentation fault.
#0 0x082e51fc in __gxx_personality_v0 ()
at ../../../../gcc-4.1.2/libstdc++-v3/libsupc++/eh_personality.cc:349
349 ../../../../gcc-4.1.2/libstdc++-v3/libsupc++/eh_personality.cc:
No such file or directory.
in ../../../../gcc-4.1.2/libstdc++-v3/libsupc
++/eh_personality.cc
(gdb) set logging on
Copying output to gdb.txt.
(gdb) set logging off
Done logging to gdb.txt.
(gdb) whe
#0 0x082e51fc in __gxx_personality_v0 ()
at ../../../../gcc-4.1.2/libstdc++-v3/libsupc++/eh_personality.cc:349
#1 <signal handler called>
#2 0x02eed5e2 in ?? () from /usr/lib/libGLcore.so.1
#3 0x00000001 in ?? ()
#4 0x00001403 in ?? ()
#5 0xf6dfb008 in ?? ()
#6 0x00000072 in ?? ()
#7 0x0c7c0680 in ?? ()
#8 0x02f7cdb8 in ?? () from /usr/lib/libGLcore.so.1
#9 0xf6e64000 in ?? ()
#10 0x00000000 in ?? ()
12:57 p.m.
I reported a crash to the idSoftware folks that appears to be a
Fedora
x86_64 specific libGL crash.
Which video card and which driver?
I'm not really able to provide much in the way of debugging traces other
than show that a crash is occuring in libGL. According to id, x86_64
Fedora is the only distro reporting this crash:
Core was generated by `./etqw.x86 +set developer 1 +set logfile 1'.
Program terminated with signal 11, Segmentation fault.
#0 0x082e51fc in __gxx_personality_v0 ()
at ../../../../gcc-4.1.2/libstdc++-v3/libsupc++/eh_personality.cc:349
349 ../../../../gcc-4.1.2/libstdc++-v3/libsupc++/eh_personality.cc:
No such file or directory.
in ../../../../gcc-4.1.2/libstdc++-v3/libsupc
++/eh_personality.cc
(gdb) set logging on
Copying output to gdb.txt.
(gdb) set logging off
Done logging to gdb.txt.
(gdb) whe
#0 0x082e51fc in __gxx_personality_v0 ()
at ../../../../gcc-4.1.2/libstdc++-v3/libsupc++/eh_personality.cc:349
#1 <signal handler called>
#2 0x02eed5e2 in ?? () from /usr/lib/libGLcore.so.1
#3 0x00000001 in ?? ()
#4 0x00001403 in ?? ()
#5 0xf6dfb008 in ?? ()
#6 0x00000072 in ?? ()
#7 0x0c7c0680 in ?? ()
#8 0x02f7cdb8 in ?? () from /usr/lib/libGLcore.so.1
#9 0xf6e64000 in ?? ()
#10 0x00000000 in ?? ()
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
1:26 p.m.
On Fri, 2008-02-01 at 10:57 -0800, Alan wrote:
> I reported a crash to the idSoftware folks that appears to be a
Fedora
> x86_64 specific libGL crash.
Which video card and which driver?
Closed source driver:
NVRM: loading NVIDIA UNIX x86_64 Kernel Module 169.09 Fri Jan 11 14:04:37 PST 2008
Mid-range Nvidia graphics board:
04:00.0 VGA compatible controller: nVidia Corporation G71 [GeForce 7900 GT/GTO] (rev a1)
Sean
9:07 p.m.
Em Sex, 2008-02-01 às 11:26 -0800, Sean Bruno escreveu:
On Fri, 2008-02-01 at 10:57 -0800, Alan wrote:
> > I reported a crash to the idSoftware folks that appears to be a Fedora
> > x86_64 specific libGL crash.
>
> Which video card and which driver?
>
>
Closed source driver:
NVRM: loading NVIDIA UNIX x86_64 Kernel Module 169.09 Fri Jan 11 14:04:37 PST 2008
Mid-range Nvidia graphics board:
04:00.0 VGA compatible controller: nVidia Corporation G71 [GeForce 7900 GT/GTO] (rev a1)
I also had some problems with this game, but I used this tip and I got
it working:
http://community.enemyterritory.com/forums/showthread.php?p=290876
Unfortunately, even using the pulseaudio oss wrapper I have no sound.
1:11 p.m.
On Fri, 2008-02-01 at 10:36 -0800, Sean Bruno wrote:
I reported a crash to the idSoftware folks that appears to be a
Fedora
x86_64 specific libGL crash.
I'm not really able to provide much in the way of debugging traces other
than show that a crash is occuring in libGL. According to id, x86_64
Fedora is the only distro reporting this crash:
You appear to be using the nvidia binary driver, hence you need to talk
to nvidia to get them to fix their driver. It's not a problem Fedora
can fix because nobody but nvidia has the source to their proprietary
driver.
Dan
Core was generated by `./etqw.x86 +set developer 1 +set logfile 1'.
Program terminated with signal 11, Segmentation fault.
#0 0x082e51fc in __gxx_personality_v0 ()
at ../../../../gcc-4.1.2/libstdc++-v3/libsupc++/eh_personality.cc:349
349 ../../../../gcc-4.1.2/libstdc++-v3/libsupc++/eh_personality.cc:
No such file or directory.
in ../../../../gcc-4.1.2/libstdc++-v3/libsupc
++/eh_personality.cc
(gdb) set logging on
Copying output to gdb.txt.
(gdb) set logging off
Done logging to gdb.txt.
(gdb) whe
#0 0x082e51fc in __gxx_personality_v0 ()
at ../../../../gcc-4.1.2/libstdc++-v3/libsupc++/eh_personality.cc:349
#1 <signal handler called>
#2 0x02eed5e2 in ?? () from /usr/lib/libGLcore.so.1
#3 0x00000001 in ?? ()
#4 0x00001403 in ?? ()
#5 0xf6dfb008 in ?? ()
#6 0x00000072 in ?? ()
#7 0x0c7c0680 in ?? ()
#8 0x02f7cdb8 in ?? () from /usr/lib/libGLcore.so.1
#9 0xf6e64000 in ?? ()
#10 0x00000000 in ?? ()
1:24 p.m.
On Fri, 2008-02-01 at 14:11 -0500, Dan Williams wrote:
On Fri, 2008-02-01 at 10:36 -0800, Sean Bruno wrote:
> I reported a crash to the idSoftware folks that appears to be a Fedora
> x86_64 specific libGL crash.
>
> I'm not really able to provide much in the way of debugging traces other
> than show that a crash is occuring in libGL. According to id, x86_64
> Fedora is the only distro reporting this crash:
You appear to be using the nvidia binary driver, hence you need to talk
to nvidia to get them to fix their driver. It's not a problem Fedora
can fix because nobody but nvidia has the source to their proprietary
driver.
Dan
>
> Core was generated by `./etqw.x86 +set developer 1 +set logfile 1'.
> Program terminated with signal 11, Segmentation fault.
> #0 0x082e51fc in __gxx_personality_v0 ()
> at ../../../../gcc-4.1.2/libstdc++-v3/libsupc++/eh_personality.cc:349
> 349 ../../../../gcc-4.1.2/libstdc++-v3/libsupc++/eh_personality.cc:
> No such file or directory.
> in ../../../../gcc-4.1.2/libstdc++-v3/libsupc
> ++/eh_personality.cc
> (gdb) set logging on
> Copying output to gdb.txt.
> (gdb) set logging off
> Done logging to gdb.txt.
> (gdb) whe
> #0 0x082e51fc in __gxx_personality_v0 ()
> at ../../../../gcc-4.1.2/libstdc++-v3/libsupc++/eh_personality.cc:349
> #1 <signal handler called>
> #2 0x02eed5e2 in ?? () from /usr/lib/libGLcore.so.1
> #3 0x00000001 in ?? ()
> #4 0x00001403 in ?? ()
> #5 0xf6dfb008 in ?? ()
> #6 0x00000072 in ?? ()
> #7 0x0c7c0680 in ?? ()
> #8 0x02f7cdb8 in ?? () from /usr/lib/libGLcore.so.1
> #9 0xf6e64000 in ?? ()
> #10 0x00000000 in ?? ()
>
Forgive my ignorance, but how can you tell that from my back trace?
Sean
2:05 p.m.
On Fri, 2008-02-01 at 11:24 -0800, Sean Bruno wrote:
On Fri, 2008-02-01 at 14:11 -0500, Dan Williams wrote:
> On Fri, 2008-02-01 at 10:36 -0800, Sean Bruno wrote:
> > I reported a crash to the idSoftware folks that appears to be a Fedora
> > x86_64 specific libGL crash.
> >
> > I'm not really able to provide much in the way of debugging traces other
> > than show that a crash is occuring in libGL. According to id, x86_64
> > Fedora is the only distro reporting this crash:
>
> You appear to be using the nvidia binary driver, hence you need to talk
> to nvidia to get them to fix their driver. It's not a problem Fedora
> can fix because nobody but nvidia has the source to their proprietary
> driver.
>
> Dan
>
> >
> > Core was generated by `./etqw.x86 +set developer 1 +set logfile 1'.
> > Program terminated with signal 11, Segmentation fault.
> > #0 0x082e51fc in __gxx_personality_v0 ()
> > at ../../../../gcc-4.1.2/libstdc++-v3/libsupc++/eh_personality.cc:349
> > 349 ../../../../gcc-4.1.2/libstdc++-v3/libsupc++/eh_personality.cc:
> > No such file or directory.
> > in ../../../../gcc-4.1.2/libstdc++-v3/libsupc
> > ++/eh_personality.cc
> > (gdb) set logging on
> > Copying output to gdb.txt.
> > (gdb) set logging off
> > Done logging to gdb.txt.
> > (gdb) whe
> > #0 0x082e51fc in __gxx_personality_v0 ()
> > at ../../../../gcc-4.1.2/libstdc++-v3/libsupc++/eh_personality.cc:349
> > #1 <signal handler called>
> > #2 0x02eed5e2 in ?? () from /usr/lib/libGLcore.so.1
> > #3 0x00000001 in ?? ()
> > #4 0x00001403 in ?? ()
> > #5 0xf6dfb008 in ?? ()
> > #6 0x00000072 in ?? ()
> > #7 0x0c7c0680 in ?? ()
> > #8 0x02f7cdb8 in ?? () from /usr/lib/libGLcore.so.1
> > #9 0xf6e64000 in ?? ()
> > #10 0x00000000 in ?? ()
> >
>
Forgive my ignorance, but how can you tell that from my back trace?
Google for /usr/lib/libGLcore.so.1 :) I couldn't find it in any of the
usual suspects (mesa, xorg, etc) so a quick google search found that
it's part of the nvidia binary driver packages.
So that's not to say that this problem _isn't_ ultimately caused by
something in Fedora (glibc changes, etc). But in the end when something
in Fedora changes there isn't a good way to do anything about binary
packages until the vendor does a rebuild or starts to debug the issue
themselves, since they have the source.
Dan
2:44 p.m.
Dan Williams wrote:
On Fri, 2008-02-01 at 11:24 -0800, Sean Bruno wrote:
> On Fri, 2008-02-01 at 14:11 -0500, Dan Williams wrote:
>> On Fri, 2008-02-01 at 10:36 -0800, Sean Bruno wrote:
>>> I reported a crash to the idSoftware folks that appears to be a Fedora
>>> x86_64 specific libGL crash.
>>>
>>> I'm not really able to provide much in the way of debugging traces other
>>> than show that a crash is occuring in libGL. According to id, x86_64
>>> Fedora is the only distro reporting this crash:
>> You appear to be using the nvidia binary driver, hence you need to talk
>> to nvidia to get them to fix their driver. It's not a problem Fedora
>> can fix because nobody but nvidia has the source to their proprietary
>> driver.
>>
>> Dan
>>
>>> Core was generated by `./etqw.x86 +set developer 1 +set logfile 1'.
>>> Program terminated with signal 11, Segmentation fault.
>>> #0 0x082e51fc in __gxx_personality_v0 ()
>>> at ../../../../gcc-4.1.2/libstdc++-v3/libsupc++/eh_personality.cc:349
>>> 349 ../../../../gcc-4.1.2/libstdc++-v3/libsupc++/eh_personality.cc:
>>> No such file or directory.
>>> in ../../../../gcc-4.1.2/libstdc++-v3/libsupc
>>> ++/eh_personality.cc
>>> (gdb) set logging on
>>> Copying output to gdb.txt.
>>> (gdb) set logging off
>>> Done logging to gdb.txt.
>>> (gdb) whe
>>> #0 0x082e51fc in __gxx_personality_v0 ()
>>> at ../../../../gcc-4.1.2/libstdc++-v3/libsupc++/eh_personality.cc:349
>>> #1 <signal handler called>
>>> #2 0x02eed5e2 in ?? () from /usr/lib/libGLcore.so.1
>>> #3 0x00000001 in ?? ()
>>> #4 0x00001403 in ?? ()
>>> #5 0xf6dfb008 in ?? ()
>>> #6 0x00000072 in ?? ()
>>> #7 0x0c7c0680 in ?? ()
>>> #8 0x02f7cdb8 in ?? () from /usr/lib/libGLcore.so.1
>>> #9 0xf6e64000 in ?? ()
>>> #10 0x00000000 in ?? ()
>>>
> Forgive my ignorance, but how can you tell that from my back trace?
You can usually get a response from the nvidia developers for the linux driver,
in particular Zander pays close attention to the forums, at www.nvnews.net.
With some debugging information like this they may be able to address it.
Did you install this from the livna repo packages? Or did you install it via
the nvidia installer? The compilation flags may matter when to post to the
forum. It looks as if you've installed via the nvidia installer script, because
the livna packages place the libraries at /usr/lib/nvidia instead.
Is this a crash that happens while playing or does the game not render at all?
What are you doing to provoke it and when does it happen? These things you
should clearly state there. The eq engine is open enough that with the right
information they should be able to track it down.
--
Andrew Farris <lordmorgul(a)gmail.com> www.lordmorgul.net
gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3
No one now has, and no one will ever again get, the big picture. - Daniel Geer
---- ----
2:46 p.m.
Sean Bruno wrote:
On Fri, 2008-02-01 at 14:11 -0500, Dan Williams wrote:
> On Fri, 2008-02-01 at 10:36 -0800, Sean Bruno wrote:
>> I reported a crash to the idSoftware folks that appears to be a Fedora
>> x86_64 specific libGL crash.
You also haven't reported the Fedora version, kernel version, nvidia driver
version; they all matter ALOT for that crash.
--
Andrew Farris <lordmorgul(a)gmail.com> www.lordmorgul.net
gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3
No one now has, and no one will ever again get, the big picture. - Daniel Geer
---- ----
3:30 p.m.
On Fri, 2008-02-01 at 10:36 -0800, Sean Bruno wrote:
> I reported a crash to the idSoftware folks that appears to be a Fedora
> x86_64 specific libGL crash.
>
> I'm not really able to provide much in the way of debugging traces other
> than show that a crash is occuring in libGL. According to id, x86_64
> Fedora is the only distro reporting this crash:
You appear to be using the nvidia binary driver, hence you need to talk
to nvidia to get them to fix their driver. It's not a problem Fedora
can fix because nobody but nvidia has the source to their proprietary
driver.
The reason I asked which driver is because of the nVIDIA proprietary
driver...
If the Mesa drivers get updated and replace the nVIDIA specific video
OpenGL drivers, this sort of crash can occur.
If you are not using the legacy drivers, you will want to try upgrading.
(The new drivers do not have this problem, according to the release
notes.) If not, then just rebuild and reinstall the drivers and see if it
fixes the problem.
I don't know how the Livna package handles this problem. I do not use the
Livna packages. I just rebuild from the nVIDIA installer/build script.
Dan
>
> Core was generated by `./etqw.x86 +set developer 1 +set logfile 1'.
> Program terminated with signal 11, Segmentation fault.
> #0 0x082e51fc in __gxx_personality_v0 ()
> at ../../../../gcc-4.1.2/libstdc++-v3/libsupc++/eh_personality.cc:349
> 349 ../../../../gcc-4.1.2/libstdc++-v3/libsupc++/eh_personality.cc:
> No such file or directory.
> in ../../../../gcc-4.1.2/libstdc++-v3/libsupc
> ++/eh_personality.cc
> (gdb) set logging on
> Copying output to gdb.txt.
> (gdb) set logging off
> Done logging to gdb.txt.
> (gdb) whe
> #0 0x082e51fc in __gxx_personality_v0 ()
> at ../../../../gcc-4.1.2/libstdc++-v3/libsupc++/eh_personality.cc:349
> #1 <signal handler called>
> #2 0x02eed5e2 in ?? () from /usr/lib/libGLcore.so.1
> #3 0x00000001 in ?? ()
> #4 0x00001403 in ?? ()
> #5 0xf6dfb008 in ?? ()
> #6 0x00000072 in ?? ()
> #7 0x0c7c0680 in ?? ()
> #8 0x02f7cdb8 in ?? () from /usr/lib/libGLcore.so.1
> #9 0xf6e64000 in ?? ()
> #10 0x00000000 in ?? ()
>
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
3:57 p.m.
Alan wrote:
I don't know how the Livna package handles this problem. I do
not use the
Livna packages. I just rebuild from the nVIDIA installer/build script.
They do. The libraries are relocated which prevents them being overwritten by
mesa, so no conflicts happen the way they used to installing by script.
--
Andrew Farris <lordmorgul(a)gmail.com> www.lordmorgul.net
gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3
No one now has, and no one will ever again get, the big picture. - Daniel Geer
---- ----
8:09 a.m.
On 01.02.2008 22:57, Andrew Farris wrote:
Alan wrote:
> I don't know how the Livna package handles this problem. I do not use the
> Livna packages. I just rebuild from the nVIDIA installer/build script.
They do. The libraries are relocated which prevents them being overwritten by
mesa, so no conflicts happen the way they used to installing by script.
Correct.
But FYI: some software has a hardcoded rpath on /usr/lib/libGL.so.1 --
if that the case the solution from livna doesn't work (I have heard ET
is a software where that's the case). The livna maintainer some weeks
ago on this list asked if alternatives could be used for libGL.so.1, but
the discussion faded out quickly without any progress/solution.
CU
knurd
5929
days inactive
5931
days old
11 comments
6 participants
participants (6)
-
Alan -
Andrew Farris -
Dan Williams -
Igor Pires Soares -
Sean Bruno -
Thorsten Leemhuis