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

Re: Bug#779467: dpkg: start-stop-daemon sometimes exits with "_cpu_tick_frequency: no such symbol" on kFreeBSD



we will never see a stable version of GNU/KFreeBSD ?

happy hacking

paolo

2015-03-02 2:46 GMT+01:00, Jeff Epler <jepler@unpythonic.net>:
> 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
>


Reply to: