aiju found a bug in port/sysproc.c sysrfork(). in the
RFPROC|RFNOMNT case, it sets up->pgrp->noattach
instead of p->pgrp->noattach setting the *parents*
noattach flag instead of the childs pgrp.
http://code.google.com/p/plan9front/source/detail?r=7bbd45940626e92d4caf11620423a96a3fdc58ad
--
cinap
small additional note. RFPROC|RFNOMNT alone makes no difference
of course as parent and child will share the same pgrp. but
with RFNAMEG or RFCNAMEG it makes a difference.
the number of programs that use this combination is probably
very small. it was triggered with irc7 which is not part of
the p
Hello,
I got a broken dns snapshot.
You can download from:
http://plan9.aichi-u.ac.jp/dns.snap.gz
Kenji Arisawa
very good. thanks.
one wired thing is that the string pointer (0xfb900) it
tried to free (char *domain) points in the middle of the
querylck array of a allocated DN.
thats not a valid alloc block indeed.
there migh'v been a block there, but it got accidently freed
and then the space reused for
if (ds->dir) {
> strncpy(ds->dir, conn->dir, NETPATHLEN);
> ds->dir[NETPATHLEN] = '\0';
i think this is okay, since the definition is
chardir[NETPATHLEN+1];
- erik
no.
just look at all the call sites for announce() and dial().
ghost drivers! ghost drivers everywhere!
--
cinap
On Mon Aug 27 22:11:14 EDT 2012, cinap_len...@gmx.de wrote:
> no.
>
> just look at all the call sites for announce() and dial().
ah, you're right about dial. i misread that. i incorrectly considered
the Conn and not the DS. both dial and announce could use a parameter
declaring the size of the
