Bug#188079: close() and/or fork() misbehaving
At 09 Apr 2003 10:53:13 +0200,
Wouter Verhelst wrote:
> Op wo 09-04-2003, om 01:55 schreef GOTO Masanori:
> > > Since I did not modify any C code in this package at the time the bug
> > > appeared, the problem must lie somewhere else. Running nbd-server in
> > > strace shows that it accept()s the client's call, then fork()s, as it
> > > should. Next, when the parent does a close() of the socket acquired with
> > > accept(), a FIN packet is sent to the client, closing the connection,
> > > although the child process still has the socket open. When it tries to
> > > send() something through that socket, it of course gets a SIGPIPE.
> > >
> > > Attached, the two files that form the output of
> > >
> > > strace -ff -o nbd-server-trace nbd-server 1234 /export/m68k/exp-bl-dev
> >
> > Why did you assign this bug to libc6 with grave severity?
>
> Sorry, I indeed forgot to lower the severity. It's a cloned bug that is
> indeed a valid grave bug for nbd, but not for libc6. Changed that with
> this message.
OK, thanks :)
> If I'm not the only one with this problem, it might be a higher severity
> than normal, though; I'll leave that up to you.
>
> > What is the
> > problem? Which version was it worked?
>
> The differences between nbd-server 1:2.3-4 and 1:2.3-6 is only
> differences of packaging; I converted to po-debconf, and added some
> translations from ddtp.d.o. There were no modifications to the C source.
>
> However, 1:2.3-4 works, while 1:2.3-6 doesn't. This leads me to believe
> it's a problem with either libc6, binutils, or gcc. I assigned the bug
> to libc6 because that seemed the most valid candidate to me; however, it
> might be that I'm misguided, and that the bug is in fact not libc6's
> fault. To be sure, I ran nbd-server from within gdb, and checked what
> happened; it looked as if the socket for the child process was closed
> when the parent closed it, which obviously is incorrect.
Umm, I recommend you that this kind of bug post to mailing lists in
first... In addition, is this close()/fork() issue really the root of
the problem? Could you provide me why close()/fork() is the problem?
I have never used nbd, so nbd expert (you) are appropriate to track
this bug.
> IIRC, 1:2.3-4 was compiled using libc6 2.3.1-1, because I remember
> waiting for it to be on my system. 1:2.3-6 has been compiled using an
> up-to-date sid system, last week.
libc6 is updated between 2.3.1-1 and 2.3.1-16, so network function may
be changed. libc6-dev 2.3.1-1 uses kernel 2.4.19 headers, but
2.3.1-16 uses 2.4.20 headers (on i386).
> > If I can not get valid
> > information, I reassign this bug back to package nbd.
>
> What extra information do you want me to provide?
nbd-* pacakges touch kernel modules, so is kernel version same between
2.3-4 and 2.3-6?
BTW, original bug submitter says:
> Apr 3 12:45:14 server nbd_server[15928]: Could not find size of exported block device: Inappropriate ioctl for device
This is in nbd-server.c::size_autodetect(). Repeatedly is this issue
related to close()/fork()?
Regards,
-- gotom
Reply to: