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
------------------------------------------------------------------------------
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
_______________________________________________
Gambas-user mailing list
Gambas-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gambas-user
