----- Original Message -----
> On 11/12/13 10:28, Nathan Scott wrote:
> > ..
> > No bells ringing - but it looks like the test greps on IPv6 in pmwebd.log
> > and conditionally attempts to curl(1) a localhost6 address if that grep
> > finds anything ... src/pmwebapi has this that its looking for:
> >
> > main.c: fprintf (f, "Started daemon on IPv6 TCP port %d\n", port);
> >
> > somehow we appear to be starting up an IPv6 port in libmicrohttpd. Does
> > "pmconfig -L | grep ipv6" agree that there's no IPv6 on this machine? I
> > guess "grep localhost6 /etc/hosts" gives nothing either way, right?
>
> According to pmconfig -L ...
>
> ipv6=true
>
> but I thought that just meant the platform supported IPv6, not that it was
> actually enabled.
Its somewhat dynamic - does an access(/proc/net/if_inet6, F_OK) to determine
whether to report true/false on Linux.
> No localhost6 in /etc/hosts (already checked that), but did find these that
> may be related ...
>
> $ grep ip6 /etc/hosts
> ::1 ip6-localhost ip6-loopback
Yeah, looks like ipv6-localhost here is equiv to localhost6 from Fedora/RHEL.
Perhaps another auto-qa-/etc/hosts-updater-script is in order here, to ensure
we always have a localhost6 entry? Or, notrun it if we cannot find a name we
expect?
>
> Using ip6-localhost instead of localhost6 in qa/660 exposes a REAL problem
> ... pmwebd dumps core at startup.
>
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x0000000000000000 in ?? ()
> (gdb) where
> #0 0x0000000000000000 in ?? ()
> #1 0x00007ffff7bd2a50 in select () from /usr/lib/libtsocks.so
Hmm - select() is coming from libtsocks and not libc? LD_LIBRARY_PATH set?
If so, does it fail the same way without it set?
> #2 0x00007ffff5da0974 in ?? () from /lib/x86_64-linux-gnu/libgcrypt.so.11
> ...
> #6 0x00007ffff6064697 in ?? () from /usr/lib/x86_64-linux-gnu/libgnutls.so.26
> ...
Sailing somewhere deep in SSL/TLS territory, on the good ship libmicrohttpd.
cheers.
--
Nathan
|