nmh-workers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nmh-workers] outstanding patches


From: Harald Geyer
Subject: Re: [Nmh-workers] outstanding patches
Date: Thu, 26 May 2005 15:44:29 +0200

>   | Obviously nmh does depend upon errno being unchanged, so it's the fault
>   | of nmh itself not linux.
> 
> That would be correct.   In that case one might wonder though why the bug
> is only observed under linux?

I don't see any reason why this bug should only be observable on linux other
than that linux is widely spread and thus nmh gets more testing on linux
than on other systems.

If everything goes right, then syscalls don't fail and errno isn't
checked so the bug doesn't show up very often ...

> I haven't seen the bug report, would you care to indicate exactly where
> the problem occurs (and the symptoms observed) ?   (Private mail if you
> prefer).

Please see http://bugs.debian.org/143485 for the whole story.

>   | (Indeed I overlooked, that this is 
>   | a bug even if fork() is used instead.
> 
> It would be, yes, though the bug might be harder to spot, as fork()
> when it succeeds most probably doesn't alter errno.

Yes, that's the reason why I didn't consider this a bug by itself. And
actually replacing vfork by fork solved the problem ... But of course
you are right and we shouldn't rely on errno being unchanged.

>   | However, I guess it's still a bad
>   | idea to use any syscalls between vfork() and exec() - so actually it's
>   | two bugs to be fixed...)
> 
> No, sys calls are generally fine (it does depend what they do, read() would
> not be a good idea... except perhaps into a local buffer in a function
> called by the child process) - in fact, sys calls are expected, the child
> has a new open file table already, and is allowed to manipulate that, and
> usually is expected to manipulate that, before the exec.   What is generally
> required though is that only genuine sys calls be used (e.g. even though I
> mentioned exit(), I really meant the sys call exit(2), not the libc exit(3).
> After a vfork, before exec, the child generally needs to use _exit() to avoid
> fooling with the parent's stdio structures).

Hm, ok then this probably isn't that much of an issue as I thought before.
Is fprintf(stderr, "...") ok? After all it should be unbuffered?

Harald





reply via email to

[Prev in Thread] Current Thread [Next in Thread]