[Gambas-user] Interest in a difficult bug?

[Tobias Boege]

On Sat, 10 Aug 2013, Tobias Boege wrote:
> No tasks involved.
> 
> I've got a minimal project working! It's not that I wasn't minded giving you
> the real project but it isn't just more complex but also needs other
> software installed and set up which I didn't want to bother you with.
> 
> Finally, there is a project attached. Its goal is to spawn a sleeping child
> process which shall detach from the Gambas process. This way, the process
> can run in the background and even survive the Gambas parent process. In
> fact, Gambas doesn't even know that the process exists (because it detached
> from the shell which was started by the Gambas program into a new session
> and the shell died) so Gambas doesn't want to wait for the started child to
> terminate.
> 
> In the example, the called program is "sleep". Normally, this would be a
> server or something which is intended to survive the starting program.
> 
> The second goal of the program is, whenever the sleep program crashes, to
> restart it. To this end, it creates an instance of a shell script. Let $PID
> denote the PID of the sleep process:
> 
> while test -d /proc/$PID; sleep 1; done
> 
> This process will terminate as soon as the sleep process terminated. As we
> can safely keep this shell script in a Process object (it is not meant to
> survive the Gambas program), we can use its Kill event to detect the
> detached sleep process' termination and start a new sleep accordingly.
> 
> Enough of the theory. I found two reliable ways to crash the interpreter:
> 
> 1) Segfault.
>    1. Start the attached program;
>    2. Open a terminal and run "pkill sleep" (or kill the sleep process some
>       other way). You should see the program reacting on the external crash;
>       it spawns a new sleep process and documents that with Debug output;
>    3. Re-run "pkill sleep". You should see a Segfault.
> 
> 2) Oops.
>    1. Start the attached program;
>    2. Hit enter in the console window to initiate a "controlled kill" by the
>       project itself;
>    3. Repeat Step 2;
>    4. Open a terminal and run "pkill sleep" to provoke an external kill;
>    5. Repeat Step 2. The oops is about a Bad file descriptor when writing
>       signal #17 (SIGCHLD) to the signal pipe.
> 
> Actually, the 2nd way doesn't seem too reliable as I *sometimes* get a
> segfault with this method, too. These two things must be related somewhere.
> 
> Hope this helps.

Oh, and maybe I should note that I circumvented these crashes in my working
project by replacing the shell script

while test -d /proc/$PID; sleep 1; done

by a Gambas Timer

Public Sub Timer_Timer()
  If Not Exist("/proc" &/ Str$($iPid)) Then HandleCrash()
End

So it has certainly something to do with that very Process object being
messed around with (yes, I admit it)...

Regards,
Tobi