[Gambas-user] Interest in a difficult bug?

[Benoît Minisini]

Le 10/08/2013 18:57, Tobias Boege a écrit :
> 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
>

No crash at all there. The line:
	
	Shell "setsid sleep 10000" Wait

never returns until the sleep is exausted or if I kill it manually. Then 
we enter the next loop which never terminate, as "pgrep sleep" now 
always return nothing.

-- 
Benoît Minisini