[Gambas-user] Interest in a difficult bug?

[Tobias Boege]

On Sat, 10 Aug 2013, Beno?t Minisini wrote:
> Le 10/08/2013 17:33, Beno?t Minisini a ?crit :
> > Le 10/08/2013 14:06, Tobias Boege a ?crit :
> >> Hi Benoit,
> >>
> >> in a project I can reliably reproduce the following message:
> >>
> >> ** Oops! Internal error! **
> >> ** Cannot write signal #17 into signal pipe: Bad file descriptor
> >> ** Program aborting. Sorry! :-(
> >> ** Please send a bug report at gambas at ...1...
> >>
> >> Tough, I didn't succeed in isolating the cause. The code deals with one
> >> Process object only but uses Exec and Shell quite often. The project also
> >> has to deal with some race conditions.
> >>
> >> I have meanwhile removed that Process object from the code and refactored
> >> that part in pure Gambas. My project works flawlessly now.
> >>
> >> Anyway, are you interested in fixing this issue? I mean, this looks
> >> like a
> >> bit of work to me (particularly because I have no minimal example for
> >> you)
> >> and I, for sure, did strange things in the code.
> >>
> >> Regards,
> >> Tobi
> >>
> >
> > Of course I'm interested. But I need more precise details, and some way
> > to reproduce it if possible.
> >
> 
> Do you use tasks? Do you run processes inside tasks?
> 

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.

Regards,
Tobi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: program-restart-oops-0.0.1.tar.gz
Type: application/octet-stream
Size: 5399 bytes
Desc: not available
URL: <http://lists.gambas-basic.org/pipermail/user/attachments/20130810/8a6ffa03/attachment.obj>