Linux client hangs when trying to quit

[aardbei]

Hi,

With the old and with the new client EL hangs when I try to close it. It just stops responding and the window doesn't close. Does anybody else have this problem, or does anybody know how to solve it?

Edited September 24, 2005 by aardbei

[CodeWarrior]

I can verify this happening to me as well.

 

I noticed that when my audio device was being used elsewhere and EL couldn't get it, the game exits normally, so I'm pretty sure it's something to do with the shutdown of the audio engine.

 

If nobody else can get around to this in the near future, I might take a stab at it, but soon I'm going to need to get some assignments done ^_^ (That and the fact that I've never tried debugging a crashing shutdown...)

[Mr_Maniac]

That's true...

It really seems to be audio-related.

I already made an bug-report.

Wytter attached a little patch-file, but unfortunately it doesn't work

[aardbei]

That's true...

It really seems to be audio-related.

I already made an bug-report.

Wytter attached a little patch-file, but unfortunately it doesn't work

Where can I find that patch, can you post a link plz?

[CodeWarrior]

Found it here, I haven't tried it myself:

Here

[Grum]

I used to have this problem. Updating openal seemed to work. I'm currently using the Gentoo openal-20050504-r1 build

[Wytter]

Perhaps we should make that a dependency instead of the one from 2002 then.

 

Let me know if it works.

[Mr_Maniac]

I have the gentoo-version openal-20050504-r1...

And well...

In short:

It doesn't work

I'll try to recompile it (openal)...

[aardbei]

I used to have this problem. Updating openal seemed to work. I'm currently using the Gentoo openal-20050504-r1 build

201119[/snapback]

I'm already using that version, so I think it really is a bug in EL. Hope they fix it soon.

[Zep]

funnily enough this used to happen on win32, strange that now its fixed there, it migrates to us =)

 

On FreeBSD, i just get

 

[Switching to Thread 5 (LWP 100159)]
stream_music (buffer=32769) at sound.c:563
563         int  size = 0;
(gdb) bt full
#0  stream_music (buffer=32769) at sound.c:563
       data = Error accessing memory address 0xbfabbee0: Bad address.

 

Whenever i try to enable sound and i log in.

Edited September 26, 2005 by Zep

[ttlanhil]

from what I've read here, sounds like a problem here:

have_music=0;
SDL_WaitThread(music_thread,&done);

ie: the music thread doesn't end itself quickly (the other person I talked to said that it would return a couple minutes later)

 

I don't have this problem, so I can't test myself, but I hope that

#config_save & fix to save config past the *nix exit hang will fix the problem (even if it does hang, your settings will be saved with this patch, and you can sigkill it)

someone who has the problem, please try this patch and let me know if it also stops the hang

 

funnily enough this used to happen on win32, strange that now its fixed there, it migrates to us =)

 

On FreeBSD, i just get

 

[Switching to Thread 5 (LWP 100159)]
stream_music (buffer=32769) at sound.c:563
563         int  size = 0;
(gdb) bt full
#0  stream_music (buffer=32769) at sound.c:563
       data = Error accessing memory address 0xbfabbee0: Bad address.

 

Whenever i try to enable sound and i log in.

201342[/snapback]

err... I think that looks like a slightly different problem 8^P

[CodeWarrior]

It's a problem with OpenAL. Gentoo users will find that neither of the 2005-05-04 versions will work with EL, but I did get the problem solved with downgrading to 2004-08-17.

 

I did a quick GDB on it and the backtrace looks like this:

#0  0xffffe410 in __kernel_vsyscall ()
#1  0xb7e6b19e in __lll_mutex_lock_wait () from /lib/libpthread.so.0
#2  0xb7e67fa8 in _L_mutex_lock_27 () from /lib/libpthread.so.0
#3  0x00000001 in ?? ()
#4  0x00000000 in ?? ()
#5  0x00000000 in ?? ()
#6  0xb7c4f59c in ?? () from /usr/lib/libopenal.so.0
#7  0x000000e0 in ?? ()
#8  0xb7c4f358 in ?? () from /usr/lib/libopenal.so.0
#9  0x00009000 in ?? ()
#10 0xb7c4dabf in canon_max () from /usr/lib/libopenal.so.0
#11 0xbf8043d8 in ?? ()
#12 0xb7c3f811 in Posix_LockMutex () from /usr/lib/libopenal.so.0
#13 0xb7c3f811 in Posix_LockMutex () from /usr/lib/libopenal.so.0
#14 0xb7c265b0 in _alLockMixerPause () from /usr/lib/libopenal.so.0
#15 0xb7c40c46 in alcMakeContextCurrent () from /usr/lib/libopenal.so.0
#16 0xb7c4543b in alutExit () from /usr/lib/libopenal.so.0
#17 0x0809a011 in destroy_sound () at sound.c:777
#18 0x080821c8 in start_rendering () at main.c:172
#19 0x080822d6 in main (argc=-4, argv=0xfffffffc) at main.c:220

(Line 777 being this:)

   alutExit();

 

I can't say that I see a workaround for the newer version of OpenAL other than to downgrade....

 

I would comment on your patch ttlanhil, but either due to my inexperience or otherwise, I couldn't seem to get it applied using "patch -p1 < some-patch.diff"

 

hth

 

edit: forgot the code tags...

Edited September 27, 2005 by CodeWarrior

[ttlanhil]

I would comment on your patch ttlanhil, but either due to my inexperience or otherwise, I couldn't seem to get it applied using "patch -p1 < some-patch.diff"

201743[/snapback]

aiee! grr @ my keyboard... has an 's' at the end of the file where i went ctrl+s to save... sigh (my fault)

 

the relevant part is an explicit call to turn_music_off(); before waiting for the music thread to end (this is where the problem is, perhaps alutexit() is being called before everything is cleaned up or something)

 

originally this patch was just so people could save their settings even if they had the hang-on-exit, just one more line where I hope the problem can be fixed

[CodeWarrior]

Even after removing the s, I got the following:

 

patching file main.c
Hunk #1 FAILED at 135.
Hunk #2 FAILED at 143.
Hunk #3 FAILED at 157.
3 out of 3 hunks FAILED -- saving rejects to file main.c.rej
patching file console.c
Hunk #1 FAILED at 437.
1 out of 1 hunk FAILED -- saving rejects to file console.c.rej
patching file init.c
Hunk #1 FAILED at 78.
Hunk #2 FAILED at 194.
2 out of 2 hunks FAILED -- saving rejects to file init.c.rej

 

doesn't matter, I explicitly added turn_music_off(); before the SDL_WaitThread(); and it didn't seem to help at all.

[ttlanhil]

Even after removing the s, I got the following:

 

patching file main.c
Hunk #1 FAILED at 135.
Hunk #2 FAILED at 143.
Hunk #3 FAILED at 157.
3 out of 3 hunks FAILED -- saving rejects to file main.c.rej
patching file console.c
Hunk #1 FAILED at 437.
1 out of 1 hunk FAILED -- saving rejects to file console.c.rej
patching file init.c
Hunk #1 FAILED at 78.
Hunk #2 FAILED at 194.
2 out of 2 hunks FAILED -- saving rejects to file init.c.rej

every single hunk failed? uhm. did you copy'n'paste from the browser window into a text document? or run dos2unix or similar? (you'll have to, because when I send the patch it'll have windows EOL characters)

doesn't matter, I explicitly added turn_music_off(); before the SDL_WaitThread(); and it didn't seem to help at all.

201750[/snapback]

darn. oh well, thank you... wonder what else could be done to force the client to close the thead... maybe create another thread with a 5sec timer to kill the client, music ended or not

[CodeWarrior]

I'm not sure I trust myself trying that Given the backtrace I posted above though, there seems to be a problem with a mutex. I don't know much about them, having just done a rather quick search on the net for what it is.

 

Is there a possibility that OpenAL is waiting for a resource lock while something else is holding it? (If I've gotten my head around it properly...)