Re: [misterhouse-users] Return code of system and exec wrong?

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

The problem did start with 2.52 on my system.

On Friday 03 August 2001 10:53 pm, you wrote:
> Sorry for the delay here.  I finialy had a chance to review my notes for a
> few more clues.   Looks like it was on release 2.52 that we changed the
> $SIG{CHLD} handler and switched from system to fork calls in &play.  Does
> that line up to when you guys started having problems with play files being
> repeated?
>
> If so, then we should be able to fix this.   Did anyone who is now seeing
> the multiple play problem not see it in 2.52+ releases?
>
> Assuming the problem was introduced in 2.52, those changes were to help mh
> run on OS X.  The note I got from Greg Satz says he had the same problem on
> OS X pre 2.52 (bad rc from system call -> multiple plays).   He got it
> working by swtiching to fork and adding a $SIG{CHLD} handler with a call to
> wait.
>
> Looks like for some reason unknown to me, I messed up his change.  Instead
> of replacing:
>
>     $SIG{CHLD}  = 'IGNORE';
>
> with
>
>     $SIG{CHLD} = \&child_death;
>
> I left the first and put the 2nd within &child_death.  I don't remember why
> I did that, but I wonder if simply moving it up to where all the other SIGs
> are defined (replacing the IGNORE one) would help.
>
> On my box, play works find with/without child_death, so I'm afraid we will
> have to rely on you guys with the problem to help verify the fix.
>
> Bruce
>
> > Will try if that also works.
> >
> > Yesterday I have come across alot of perl related sites
> > with info on SIGs and forks() and exec() etc.
> >
> > I have seen some code to reactivate / change the
> > SIG handler in certain points of the code.
> >
> > Some sites claim you need to set the SIG{CHLD} = wait()
> > to be able to get correct return codes of forked processes.
> >
> > > You may want to change
> > > $SIG{CHLD} = "IGNORE";
> > >
> > > to
> > >
> > > local $SIG{CHLD} = "IGNORE";
> > >
> > > Of course, whether or not it works depends on where they
> >
> > SIG{CHLD} handler is being set.
> >
> > > > Is this the reason the fork() return codes still fail
> > > > as mentioned in my last e-mail???:
> > > >
> > > >
> > > > Why doesn't open() return an error when a pipe open fails?
> > > >
> > > >      Because the pipe open takes place in two steps: first Perl
> > > >      calls fork() to start a new process, then this new process
> > > >      calls exec() to run the program you really wanted to open.
> > > >      The first step reports success or failure to your process,
> > > >      so open() can only tell you whether the fork() succeeded or
> > > >      not.
> > > >
> > > >      To find out if the exec() step succeeded, you have to catch
> > > >      SIGCHLD and wait() to get the exit status.  You should also
> > > >      catch SIGPIPE if you're writing to the child--you may not
> > > >      have found out the exec() failed by the time you write.
> > > >      This is documented in the perlipc manpage.
> > > >
> > > >      In some cases, even this won't work.  If the second argument
> > > >      to a piped open() contains shell metacharacters, perl
> > > >      fork()s, then exec()s a shell to decode the metacharacters
> > > >      and eventually run the desired program.  Now when you call
> > > >      wait(), you only learn whether or not the shell could be
> > > >      successfully started.  Best to avoid shell metacharacters.
> > > >
> > > >      On systems that follow the spawn() paradigm, open() might do
> > > >      what you expect--unless perl uses a shell to start your
> > > >      command. In this case the fork()/exec() description still
> > > >      applies.
> > > > -----------
> > > >
> > > >
> > > >
> > > > If I understand correctly change the SIGCHLD IGNORE to:
> > > >
> > > >      SIGCHLD and wait() to get the exit status
> > > >
> > > >
> > > > Regards,
> > > > Ron.
> > > >
> > > > BTW: Sorry if this is gonna be a long thread, but I can stand it
> > > > if something doesn't work the way it should ;)
> > > >
> > > > ----- Original Message -----
> > > > From: "Ron Klinkien" <ro...@za...>
> > > > To: <mis...@li...>
> > > > Sent: Monday, July 30, 2001 9:53 PM
> > > > Subject: Re: [misterhouse-users] Return code of system and exec
> > > > wrong?
> > > >
> > > > > Hi Bruce,
> > > > >
> > > > > For a change I reply on my own mail. ;-)
> > > > >
> > > > > I have been looking at the system() return code problem,
> > > > > and found at least the reason why the older routine of
> > > > > simply calling system() to play a sound also failed.
> > > > >
> > > > >          system("$config_parms{sound_program} $file &");
> > > > >
> > > > > When printing the $! of this system call I got:
> > > > >
> > > > > No child processes
> > > > >
> > > > > It returned this error because of line 483 in bin/mh: (v2.55)
> > > > >  $SIG{CHLD}  = 'IGNORE';                   # So we don't create
> >
> > zombies
> >
> > > > when
> > > >
> > > > > forking
> > > > >
> > > > > If you put an # infront, the return code of the system calls are 0
> >
> > which
> >
> > > > is
> > > >
> > > > > good ;)
> > > > >
> > > > > Maybe thats the reason this gave problems on OS X as you
> >
> > mentioned in
> >
> > > > the
> > > >
> > > > > comments?
> > > > >
> > > > > It doesn't solve the original new soundplay code using "exec qq"
> >
> > though.
> >
> > > > > I get "Resource temporarily unavailable" as #! text.
> > > > >
> > > > > But it has to be the same kind of trick I guess since a
> >
> > clean play.pl
> >
> > > > with
> > > >
> > > > > the same code works ok.
> > > > >
> > > > >
> > > > > Reading a page on perl return codes (
> > > > > http://www.weird-wonderful.com/p5be/ch13.cfm )
> > > > > gave me the idea it's not that reliable in every situation.
> > > > >
> > > > > Regards,
> > > > > Ron.
> > > > >
> > > > > BTW: I'm running perl, version 5.005_03 built for i386-freebsd
> > > > >
> > > > > ----- Original Message -----
> > > > > From: "Ron Klinkien" <ro...@za...>
> > > > > To: <mis...@li...>
> > > > > Sent: Monday, July 30, 2001 3:04 PM
> > > > > Subject: Re: [misterhouse-users] Return code of system and
> >
> > exec wrong?
> >
> > > > > > Hi Bruce,
> > > > > >
> > > > > > As you advised I tried the simple /mh/bin/play command instead of
> > > >
> > > > waveplay
> > > >
> > > > > > (which is just a small tool to play .wav files, it also does some
> > > >
> > > > checks
> > > >
> > > > > on
> > > > >
> > > > > > the
> > > > > >  bitrate of the sound etc).
> > > > > >
> > > > > > But play has the same problem, it plays the sound ok, but when
> > > >
> > > > executed
> > > >
> > > > > > from perl it return a wrong return code (!=0) so MH tries it
> >
> > again...
> >
> > > > > > It's not only the play command which has this problem but also
> > > > > > the
> > > >
> > > > date
> > > >
> > > > > > command
> > > > > > called when syncing clocks from the inet. Which results in:
> > > > > > "System clock NOT adjusted due to time command error."s
> > > > > >
> > > > > > If I use the same perl code in a single play.pl and run that, it
> > > >
> > > > returns
> > > >
> > > > > the
> > > > >
> > > > > > correct rc.(0)
> > > > > > But if I use that code in /mh/bin/mh it goes wrong.
> > > > > > ------
> > > > > > #!/usr/bin/perl
> > > > > >  my $pid = fork;
> > > > > >  if (defined $pid && $pid == 0) {
> > > > > >    exec qq[/mh/bin/play /mh/sounds/sound_click2.wav];
> > > > > >    die 'cant exec $config_parms{sound_program}';
> > > > > >  }
> > > > > > print $?;
> > > > > > ------
> > > > > >
> > > > > >
> > > > > > It has nothing todo with the specific sound play code, but all
> >
> > exec's
> >
> > > > > (which
> > > > >
> > > > > > is
> > > > > > only used a few times) have this problem.
> > > > > >
> > > > > > With some perl commands you have to use >>8 tricks to get
> >
> > the right
> >
> > > > return
> > > >
> > > > > > code.
> > > > > > (see perldoc site).
> > > > > >
> > > > > > I have the feeling it has todo with some perl startup
> > > > > > params/stack
> > > >
> > > > when
> > > >
> > > > > used
> > > > >
> > > > > > with mh.
> > > > > > Maybe a shell environment which is incorrect so all exec's fail.
> > > > > >
> > > > > > I will try some more things later today.
> > > > > >
> > > > > > Regards,
> > > > > > Ron.
> > > > > >
> > > > > > ----- Original Message -----
> > > > > > From: "Bruce Winter" <br...@mi...>
> > > > > > To: <mis...@li...>
> > > > > > Sent: Monday, July 30, 2001 12:07 AM
> > > > > > Subject: RE: [misterhouse-users] Return code of system and exec
> >
> > wrong?
> >
> > > > > > > Just now getting back to this post from a few weeks ago ...
> > > > > > >
> > > > > > > > When my MH plays a sound I says it failed doing it
> > > > > > > > and tries it again a few times until it gives up.
> > > > > > > >
> > > > > > > > It _does_ play the sound, (5 times) but the return code is
> > > > > > > > wrong so it tries it again and again.
> > > > > > > >
> > > > > > > > The MH console lists this:
> > > > > > > > running: waveplay -s ./../sounds/sound_click2.wav
> > > > > > > > Waiting to play sound file, pass=4
> > > >
> > > > file=./../sounds/sound_click2.wav
> > > >
> > > > > > > > running: waveplay -s ./../sounds/./../sounds/sound_click2.wav
> > > > > > > > Waiting to play sound file, pass=3
> > > > > > > > file=./../sounds/./../sounds/sound_click2.wav
> > > > > > > > running: waveplay -s
> > > > > >
> > > > > > ./../sounds/./../sounds/./../sounds/sound_click2.wav
> > > > > >
> > > > > > > > Waiting to play sound file, pass=2
> > > > > > > > file=./../sounds/./../sounds/./../sounds/sound_click2.wav
> > > > > > > > running: waveplay -s
> >
> > ./../sounds/./../sounds/./../sounds/./../sounds/sound_click2.wav
> >
> > > > > > > > Waiting to play sound file, pass=1
> > > >
> > > > file=./../sounds/./../sounds/./../sounds/./../sounds/sound_click2.wav
> > > >
> > > > > > > > running: waveplay -s
> >
> > ./../sounds/./../sounds/./../sounds/./../sounds/./../sounds/sound_
> >
> > > > > > > > click2.wav
> > > > > > > > Gave up trying to play sound file:
> >
> > ./../sounds/./../sounds/./../sounds/./../sounds/./../sounds/sound_
> >
> > > > > > > > click2.wav
> > > > > > > >
> > > > > > > > So there is also a bug which appends the same sound path
> > > > > > > > again
> >
> > and
> >
> > > > > > again.
> > > > > >
> > > > > > > I just fixed this the path prepending problem (by adding a -e
> >
> > $file
> >
> > > > > test),
> > > > >
> > > > > > > but I don't think that is causing the repeated sound problem,
> > > > > > > as
> >
> > it
> >
> > > > is
> > > > a
> > > >
> > > > > > > valid path.
> > > > > > >
> > > > > > > > This code snipped returns the wrong return code: (bin/mh  in
> >
> > play
> >
> > > > > > > > subroutine)
> > > > > > > >
> > > > > > > >  my $pid = fork;
> > > > > > > >  if (defined $pid && $pid == 0) {
> > > > > > > >    exec qq[waveplay -s /mh/sounds/sound_click2.wav];
> > > > > > > >    die 'cant exec $config_parms{sound_program}';
> > > > > > > >  }
> > > > > > > >
> > > > > > > > it returns -1 therefore mh thinks it failed.
> > > > > > >
> > > > > > > So, the question is what did I change in bin/mh to cause rc=-1
> >
> > when
> >
> > > > > > calling
> > > > > >
> > > > > > > waveplay.    Can you try mh/bin/play, instead of waveplay?   I
> >
> > don't
> >
> > > > see
> > > >
> > > > > > the
> > > > > >
> > > > > > > problem here when using play.   What is waveplay and
> >
> > what is it's
> >
> > > > > > advantage?
> > > > > >
> > > > > > > Looks like there are 4 of you who reported this
> >
> > problem.  Was the
> >
> > > > > problem
> > > > >
> > > > > > > new to 2.55 and if so, what was the previous verion of mh where
> >
> > you
> >
> > > > did
> > > >
> > > > > > not
> > > > > >
> > > > > > > see the problem and what is your mh.ini sound_program
> >
> > parm set to?
> >
> > > > > > > Bruce
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > ________________________________________________________
> > > > > > > To unsubscribe from this list, go to:
> > > > > >
> > > > > > http://sourceforge.net/mail/?group_id=1365
> > > > > >
> > > > > >
> > > > > >
> > > > > > ________________________________________________________
> > > > > > To unsubscribe from this list, go to:
> > > > >
> > > > > http://sourceforge.net/mail/?group_id=1365
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > ________________________________________________________
> > > > > To unsubscribe from this list, go to:
> > > >
> > > > http://sourceforge.net/mail/?group_id=1365
> > > >
> > > >
> > > >
> > > >
> > > > ________________________________________________________
> > > > To unsubscribe from this list, go to:
> > > > http://sourceforge.net/mail/?group_id=1365
> >
> > -------------------------------------------------------------------------
> >- ----
> >
> > > This message is intended only for the personal and confidential
> >
> > use of the
> > designated recipient(s) named above.  If you are not the intended
> > recipient
> > of this message you are hereby notified that any review, dissemination,
> > distribution or copying of this message is strictly prohibited.  This
> > communication is for information purposes only and should not be
> > regarded as
> > an offer to sell or as a solicitation of an offer to buy any financial
> > product, an official confirmation of any transaction, or as an official
> > statement of Lehman Brothers.  Email transmission cannot be
> > guaranteed to be
> > secure or error-free.  Therefore, we do not represent that this
> > information
> > is complete or accurate and it should not be relied upon as such.  All
> > information is subject to change without notice.
> >
> > > ________________________________________________________
> > > To unsubscribe from this list, go to:
> >
> > http://sourceforge.net/mail/?group_id=1365
> >
> >
> >
> > ________________________________________________________
> > To unsubscribe from this list, go to:
>
> http://sourceforge.net/mail/?group_id=1365
>
>
> ________________________________________________________
> To unsubscribe from this list, go to:
> http://sourceforge.net/mail/?group_id=1365