From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6857 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: pthreads broken (freeradius testcase) Date: Fri, 16 Jan 2015 13:09:33 -0500 Message-ID: <20150116180933.GX4574@brightrain.aerifal.cx> References: <54B844B4.1000500@dd-wrt.com> <20150116082000.57abc5c9@ncopa-desktop.alpinelinux.org> <54B8F9B3.4030809@dd-wrt.com> <20150116162505.GW4574@brightrain.aerifal.cx> <54B95119.1080008@dd-wrt.com> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1421431791 26114 80.91.229.3 (16 Jan 2015 18:09:51 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 16 Jan 2015 18:09:51 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6870-gllmg-musl=m.gmane.org@lists.openwall.com Fri Jan 16 19:09:50 2015 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1YCBLA-0000xm-DW for gllmg-musl@m.gmane.org; Fri, 16 Jan 2015 19:09:48 +0100 Original-Received: (qmail 9704 invoked by uid 550); 16 Jan 2015 18:09:46 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 9693 invoked from network); 16 Jan 2015 18:09:45 -0000 Content-Disposition: inline In-Reply-To: <54B95119.1080008@dd-wrt.com> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:6857 Archived-At: 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 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