Re: pthreads broken (freeradius testcase)

[Rich Felker <dalias@libc.org>]

On Fri, Jan 16, 2015 at 06:57:45PM +0100, Sebastian Gottschall wrote:
> Am 16.01.2015 um 17:25 schrieb Rich Felker:
> >On Fri, Jan 16, 2015 at 12:44:51PM +0100, Sebastian Gottschall wrote:
> >>Am 16.01.2015 um 08:20 schrieb Natanael Copa:
> >>>On Thu, 15 Jan 2015 23:52:36 +0100
> >>>Sebastian Gottschall <s.gottschall@dd-wrt.com> wrote:
> >>>
> >>>>following test case
> >>>>
> >>>>configure freeradius with --with-threads (which is on by default)
> >>>>if you start radiusd with your radius configuration you will see that
> >>>>radius does not listen on any ports. it will hang in the listener thread
> >>>>which creates the socket.
> >>>>if you configure it as --without-threads, it works
> >>>>
> >>>>
> >>>>tested with musl 1.1.6 on a mips (big endian) system using kernel 3.10
> >>>>
> >>>>Sebastian
> >>>What version of freeradius is it?
> >>>
> >>>I have had some interesting threading issues with freeradius 2.2.x.
> >>>Some modules are marked as non-thread safe but will still run in a
> >>>separate thread. It runs main thread + a single non-thread-safe thread.
> >>>
> >>>They used getgrnam and getpwnam in both main thread and in the
> >>>non-thread-safe module so memory got corrupted. (IMHO this should get a
> >>>CVE but upstream disagrees because it only happens on a non-recommended
> >>>config)
> >>>
> >>>They fixed that in 3.x.x but AFAIK they didn't fix it in 2.x.x.
> >>>
> >>>Patches:
> >>>http://git.alpinelinux.org/cgit/aports/tree/main/freeradius/0001-Use-threadsafe-wrapper-for-getpwnam-getgrnam.patch
> >>>http://git.alpinelinux.org/cgit/aports/tree/main/freeradius/0001-use-threadsafe-rad_getgrnam.patch
> >>>
> >>>(upstream patched it differently in 3.x.x branch)
> >>>
> >>>When backporting the fix to 2.x.x I also found that the TLS configure
> >>>test is completely broke in 2.x.x branch too. IIRC it will say "TLS
> >>>found" but behind the scenes it will still disable TLS support.
> >>>
> >>>patch:
> >>>http://git.alpinelinux.org/cgit/aports/tree/main/freeradius/fix-tls-test.patch
> >>>
> >>>This is probably not the related the issue you have have at hand, but
> >>>I'm would not be surprised if musl libc has unmasked another bug in
> >>>freeradius.
> >>i applied all these fixes. the first thread for port 1812 works, the
> >>second thread for internal tunnel 18120 doesnt work
> >>an hangs again. even if setuid support is disabled
> >Could you report where the hang is occurring (using gdb backtrace) now
> >with the setuid support disabled?
> i will try my best to find it out. gdb is hard to run on embedded
> shrinked to death the firmware.  :-)

If you're familiar with debugging, it might be possible to determine
where the threads are hung without gdb. /proc/$pid/task/$tid/stat
should contain as field 30 the last-observed program-counter (aka
instruction pointer) for the thread, which can be translated into a
function address using your binaries and possibly the contents of
/proc/self/maps. This won't give a full backtrace, but combined with
the output of the strace utility it might give a good idea what code
was running when it hung.

If the above all sounds like [insert language you can't speak] to you,
though, you're probably best sticking to getting gdb running on it.

Rich