Bug 203336

Switching the maximum texture size has no effect.
However, when I switched it back to using openal,
the game segfaulted in about 30 seconds. Switching
to plib audio makes it playable as long as I would like.
System is a current RawHide.

torcs-1.2.4-3.fc5
openal-0.0.9-0.7.20060204cvs.fc6

This is possibly an openal problem. If you could install all the needed
debuginfo packages and get a useful backtrace from the crash, it would be more
useful.

I'll be releasing 1.3.0 packages very soon, you might want to also try those in
case this problem was in torcs and got fixed.

Well, I can unfortunately confirm that this problem is still present with 1.3.0,
as it segfaulted at the first curve for me too... switching to use plib for the
sound in the options seems to have prevented the problem from appearing.

Well this is not a related problem, bug you seem to have released torcs 1.3.0
data in extras but not the torcs 1.3.0 main binary and robots (according to
repoview and my updates from french mirrors) ... Not a big deal but a little bit
disturbing for torcs 1.2.4 main binary  ;-) 

Are you waiting to fix this problem before releasing torcs 1.3.0 main binary and
robots ? (and thru fixing torcs version mixup) ?

Thanks.

(In reply to comment #4)

The data was hardlinked and already pushed to the mirrors. The 1.3.0 builds for
FC5 and FC6 are still waiting for the next push, which will probably be today.

I cannot get the bug to reproduce on my class room computer nor on the computer
of my friend next to me.
We drove quick race's for 3 to 4 minutes without anything happening.
Both computers run 
TORCS version 1.3.0.1-fc6
openaL version 0.0.9-09.20060204cvs.fc6
and its clear that we run on fedora core 6

Hope this helps.

Good luck

I get the same problem on x86_64/FC5.

I have:
[daddy@arcturus ~]$ rpm -qa | grep torcs
torcs-1.3.0-1.fc5
torcs-data-cars-extra-1.3.0-1
torcs-data-1.3.0-1
torcs-data-tracks-road-1.3.0-1

and get:Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1084746048 (LWP 5745)]
0x00002aaaac24759c in alGetString () from /usr/lib64/libopenal.so.0

The program seemed to crash *whenever 2 cars crashed*. It happened like that 3
out of 3 times.

The strace looks like this (if it's any help):
...
[pid  5438] sched_yield()               = 0
[pid  5438] sched_yield()               = 0
[pid  5438] sched_yield()               = 0
[pid  5438] sched_yield()               = 0
[pid  5438] sched_yield()               = 0
[pid  5438] sched_yield( <unfinished ...>
[pid  5444] <... select resumed> )      = 1 (out [9], left {0, 798000})
[pid  5444] write(9,
"\270\25\356\f\231\26\257\rh\27m\r\214\26\266\f\323\22\34"..., 1024) = 1024
[pid  5444] select(0, NULL, NULL, NULL, {0, 1} <unfinished ...>
[pid  5438] <... sched_yield resumed> ) = 0
[pid  5438] sched_yield()               = 0
[pid  5438] sched_yield()               = 0
[pid  5438] sched_yield()               = 0
[pid  5438] sched_yield()               = 0
[pid  5438] sched_yield()               = 0
[pid  5438] sched_yield()               = 0
[pid  5438] sched_yield()               = 0
[pid  5438] sched_yield()               = 0
[pid  5438] sched_yield()               = 0
[pid  5438] sched_yield()               = 0
[pid  5444] <... select resumed> )      = 0 (Timeout)
[pid  5438] sched_yield( <unfinished ...>
[pid  5444] --- SIGSEGV (Segmentation fault) @ 0 (0) ---

If you want any more, I'll put it in a proper attachment.
Cheers.

Looks like this might be an x86_64 specific bug in openal. I'm CC'ing Hans since
he has very good C knowledge, and interest in games working as well as possible.
Hans : Do you think you could reproduce and track the problem down? From my
experience, it's pretty easy to reproduce...

I'm currently without internet at home (gasp). And I have no 64 bits machines at
work (isn't working in education great, la la la). Anyways I'll try to put the
necessary packages on my usb drive and see what I can come up with.

Ok I tried this yesterday on my 64 bits machine, running it under gdb yields a
segfault deep deep inside some openal mmx asm code. So I tried disabling the mmx
asm for x86_64, which indeed fixes this. A proper fix for this will need to be
done by openal upstream as my asm is about as good as my French :) In the mean
time this workaround does the trick.

I'll attach the patch for this shortly. Also changing the component to openal
and the assignee to the openal owner to match.

Created attachment 147654 [details]
Patch working around the crash in mmx code on 64 bit

*** Bug 244281 has been marked as a duplicate of this bug. ***

I just finished "debugging" bug 244281, which is actually a second report of
this long fixed bug. Why wasn't my patch fixing this applied to the openal
package long ago?

Probably because you attached it during the time when my spamfilter used to eat
bugzilla mails and I totally missed that. I will see that it gets applied asap.
I am really sorry for the delay.

openal-0.0.9-0.10.20060204cvs.fc7 has been pushed to the Fedora 7 testing repository.  If problems still persist, please make note of it in this bug report.

openal-0.0.9-0.10.20060204cvs.fc7 has been pushed to the Fedora 7 stable repository.  If problems still persist, please make note of it in this bug report.