[crossfire] misc.c: raiseChild() problem

[tchize]

Hello,

I did the original code of childs manipulation, raiseChild() being part of it.
The first purpose of this code was to handle easily various clientside 
scripts.
However the sound system fitted neatly into it (forking and piping commands).
That's for historical point.

Now to your problem.
Indeed when client quits immediatly, and you want to write to the sound 
process you get a SIGPIPE. That's a normal behaviour. If you look at the code 
of play_sound, you see this:
    if ( (fprintf(sound_pipe,"%4x %4x %4x %4x\n",soundnum,soundtype,x,y)<=0) 
||
     
      (fflush(sound_pipe)!=0) ){
     
             LOG(LOG_ERROR,"gtk::play_sound","couldn't write to sound pipe: 
%d",errno);
        use_config[CONFIG_SOUND]=0;
        fclose(sound_pipe);
        sound_process=NULL;
        return;
    }

I did reproduce your sigpipe, having the soundserver do a exit(-1); as first 
main() instruction. I got this in console:

[  INFO  ] (common::raiseChild) Raising /tmp/bin/cfsndserv with flags 7
[  INFO  ] (common::monitorChilds) Child /tmp/bin/cfsndserv died. Removing and 
closing pipes
[  INFO  ] (common::VersionCmd) Playing on server type  Crossfire Server
[WARNING ] (common::SetupCmd) Server returned FALSE on setup command sexp
[  INFO  ] (commands.c) addme_success received.
[ ERROR  ] (gtk::play_sound) couldn't write to sound pipe: 32

As you see, you simply detect the client is dead because the pipe is not 
working anymore, and that's what the client is doing, setting sound config to 
off as a result.
Whatever, it did not core dump, and client shouldn't core dump on a sigpipe 
(it's just an information signal, not a critical thing).
sigpipe is handled the following way:

signal(SIGPIPE, signal_pipe);
with

void signal_pipe(int i) {
    /* do nothing, but perhaps do something more in the future */
}

so it shouldn't mean a core dump.

However, according to you mail, it does core dump. Maybe it core dumps later 
as a side effect of code. So, i want you to load your core dump into gdb with 
following command:
gdb <client bin path> <core_file>

issue the following command:
thread apply all bt

and send the result to this mailing list.
Also, you may want to fill a bug report on sourceforge so we keep track of 
problem.

Thanks,

Le Samedi 29 Janvier 2005 01:37, Bob Tanner a écrit :
Debugging a problem where gcfclient was core dumping on a SIGPIPE when
 playing with sound active.

Traced it back to cfsndsrv and misc.c:raiseChild().

Not sure who maintains this code, but the raiseChild function is not catching
the error condition when the child exits with a non-zero exit condition.

I had the wrong audio device name for linux and cfsndserv.c:init_audio()
 (listed below)

int init_audio() {

  /* open the PCM device */
  if ((err = snd_pcm_open(&handle,AUDIODEV,SND_PCM_STREAM_PLAYBACK,0)) <0) {
        ALSA9_ERROR("init_audio(): ",err);
        exit(1);
  }

It seems that a child dieing is detected:

[  INFO  ] (common::monitorChilds) Child /usr/games/cfsndserv died. Removing
 and closing pipes

But the death of the child isn't communicated/tracked anywhere else, so when
play_sound() is invoked it -assumes- the cfsndserv is running.

Not familiar enough with the code to determine if I should check if the
cfsndserv is alive each time I attempt to play a sound or hack on the
raiseChild() or monitorChilds().

-- 
--
Tchize (David Delbecq)
     
     tchize at myrealbox.com
     
     
Public PGP KEY FINGERPRINT:
    F4BC EF69 54CC F2B5 4621  8DAF 1C71 8E6B 5436 C17C
Public PGP KEY location:
    
     
     http://wwwkeys.pgp.net/pgpnet/wwwkeys.html
     
     
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : 
     
     http://shadowknight.real-time.com/pipermail/crossfire/attachments/20050130/2569c7aa/attachment.pgp