Thanks all.
it's interesting that announce.c doesn't have the same problem:
cpue% grep -n NETPATHLEN /sys/src/libc/*/*.[ch]
/sys/src/libc/9sys/announce.c:73: strncpy(dir, buf, NETPATHLEN);
/sys/src/libc/9sys/announce.c:74: dir[NETPATHLEN-1] = 0;
/sys/src/libc/9sys/anno
On Sat Sep 8 23:02:25 EDT 2012, charles.fors...@gmail.com wrote:
> No, I didn't explain it well. NETPATHLEN isn't named in the manual
> pages, so ndb/dns doesn't use it. On the other hand, dial does, but
> because it's ...LEN, it's an easy mistake to think of it as the length
> of a string, whi
No, I didn't explain it well.
NETPATHLEN isn't named in the manual pages, so ndb/dns doesn't use it.
On the other hand, dial does, but because it's ...LEN, it's an easy mistake
to think of it as the length of a string, which wouldn't include the
terminating zero byte,
instead of the length of the
ah, so NETPATHLEN was introduced later and is really refering to
the number of non null characters? and there was never an official
named constant for the size of the netdir buffers for dial/annouce?
thats indeed confusing.
--
cinap
it makes perfect sense: if the length of the path is NETPATHLEN, length of
a string usually referring to
non-zero bytes, you need to allow for the terminating zero byte.
unfortunately, as you describe, it's a bit pointless because the dnsresolve
callers rely on the manual page
("The path name is gu
its pretty simple, just look where i made the <--- arrow in
my original post.
a patch would might look like this:
static int
fillinds(DS *ds, Dest *dp)
{
Conn *conn;
if (dp->winner < 0)
return -1;
conn = &dp->conn[dp->winner];
if (dp->cfdp)
I there a patch? it's not obvious from the archive posting what
should be changed.
-Skip
On Sat, Sep 8, 2012 at 11:18 AM, wrote:
> look at this:
>
> free(v=0xa7200)+0x23 /sys/src/libc/port/malloc.c:250
>
> thats exactly what happend here:
>
> http://9fans.net/archive/2012/08/249
>
> its not a
look at this:
free(v=0xa7200)+0x23 /sys/src/libc/port/malloc.c:250
thats exactly what happend here:
http://9fans.net/archive/2012/08/249
its not a double free. dial() corrupts your stack. geoff needs
to fix fial().
--
cinap
look at:
free(v=0xa7200)+0x23 /sys/src/libc/port/malloc.c:250
notice the lsb is 00 exactly like in the case i solved here:
http://9fans.net/archive/2012/08/249
i hate to repeat myself all the time. geoff needs to fix dial().
--
cinap
I'm seeing dns panics about once a day. It was built from sources that
were updated about a week ago from sources. it's a double free error.
any ideas?
cpue% acid 7196
/proc/7196/text:386 plan 9 executable
/sys/lib/acid/port
/sys/lib/acid/386
acid: stk()
abort()+0x0 /sys/src/libc/9sys/abort.c:6
10 matches
Mail list logo
