Porting on FreeBSD 53

[Greg 'groggy' Lehey]

[severely trimmed]

On Friday, 13 May 2005 at 12:45:12 -0500, Sen C. Farley wrote:
> On Fri, 13 May 2005, Hervé Kergourlay wrote:
>> Seán C. Farley a écrit :
>>> On Thu, 12 May 2005, Seán C. Farley wrote:
>>>> On Thu, 12 May 2005, Hervé Kergourlay wrote:
>>>>> 4) wait() API
>>>>>
>>>>> 2 problems, the first is a ECHILD error on a wait call after a fork
>>>>> fork The code is generic for most of unix system. Is there any
>>>>> specific problems to manage the fork and wait APIs ?  the second
>>>>> problem with calls is a blocking wait() call in the same condition
>>>>> but this time the son process is finished but the wait call in the
>>>>> father stays blocked, again it's a generic Unix code
>>>>>
>>>>> If there is no evidence, ask me for more informations
>>>>
>>>> The second problem sounds like what I am encountering
>>>> (http://www.freebsd.org/cgi/query-pr.cgi?pr=77818) with zsh for my
>>>> shell.  You did suspend (sigsuspend()) SIGCHLD before the fork?  By
>>>
>>>
>>> Ah ha!  I see the problem that has been causing me this problem and
>>> probably you too.  Signal suspensions (only these?) are not being
>>> copied with a double fork().  Here is an example program[1] to
>>> illustrate.  They do get copied on FreeBSD-4.10 and Linux.  I just do
>>> not know if they are supposed to be copied.
>>
>> I test your sample
>>
>> it's working on Linux and FreeBSD 4.0 but failing on FreeBDS 5.2 et
>> 5.3.  the process stays blocked on the suspend call
>>
>> I rewrite another sample with the same model, joined here, as we wrote
>> it in our main program. It's working also on Linux but failing on all
>> FreeBSD included FreeBSD 4.0, 5.2 et 5.3
>>
>> ...
>>
>> the wait call return with an errno ECHILD ??
>
> The children are exiting before the parents (due to sleep()'s) get to
> their wait()'s.
>
>> did you have any idea if the problem will be solve by the FreeBSD team
>> or not ?
>
> I updated my bug report and tried to notify David Xu but the e-mail
> server rejected the e-mail (too many "Received" headers).  I am also
> Cc'ing Greg Lehey since he ran into a possibly similar bug[1] in
> February.

Now that I've had time to look at it, both problems appear to be
related to signals, but that's about as far as it goes.  I wouldn't
expect any connection unless it's a general signal race condition.

Greg
--
See complete headers for address and phone numbers.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20050523/2b7994f1/attachment.bin