we will never see a stable version of GNU/KFreeBSD ?
happy hacking
paolo
2015-03-02 2:46 GMT+01:00, Jeff Epler :
> Thank you for the speedy reply!
>
> Unfortunately, with your patch, start-stop-daemon crashes.
> With valgrind (kfreebsd patches in stalled bug
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=702729) the site of
> the crash is spelled out:
>
> Invalid read of size 4
>at 0x40221B: do_findprocs (start-stop-daemon.c:1796)
>by 0x402264: do_stop (start-stop-daemon.c:1932)
>by 0x4037B3: main (start-stop-daemon.c:2117)
> Address 0x1b91e28 is 1,160 bytes inside a block of size 1,080,710 free'd
>at 0x100D1BC: free (in
> /usr/lib/valgrind/vgpreload_memcheck-amd64-freebsd.so)
>by 0x12176BE: kvm_getprocs (in /lib/libkvm.so.6)
>by 0x401EA4: ssd_kvm_get_procs (start-stop-daemon.c:1273)
>by 0x402085: pid_check (start-stop-daemon.c:1610)
>by 0x402224: do_findprocs (start-stop-daemon.c:1796)
>by 0x402264: do_stop (start-stop-daemon.c:1932)
>by 0x4037B3: main (start-stop-daemon.c:2117)
>
> .. it appears that each call to ssd_kvm_get_procs(kd) frees the result of a
> previous call to ssd_kvm_get_procs(kd). Before your patch, the kd in
> each call was distinct; but now it is the same. The manpage for
> kvm_getprocs has this to say:
> The memory allocated to the argv pointers and string storage is owned
> by
> the kvm library. Subsequent kvm_getprocs() and kvm_close(3) calls
> will
> clobber this storage.
> which seems to be exactly what is going on. Boo.
>
> If you feel that a patch that doesn't change program flow is
> lower-impact, then this alternative does run for me. It makes each
> each function with a kvm_t local declare it as static. It's the same
> idea as your patch, but pushed up a level so that one function's call to
> ssd_kvm_get_procs doesn't free the memory used in another function.
>
> Jeff
>
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
