From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6858 Path: news.gmane.org!not-for-mail From: Sebastian Gottschall Newsgroups: gmane.linux.lib.musl.general Subject: Re: pthreads broken (freeradius testcase) Date: Fri, 16 Jan 2015 22:59:33 +0100 Message-ID: <54B989C5.5090200@dd-wrt.com> 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> <20150116180933.GX4574@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1421445590 24833 80.91.229.3 (16 Jan 2015 21:59:50 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 16 Jan 2015 21:59:50 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6871-gllmg-musl=m.gmane.org@lists.openwall.com Fri Jan 16 22:59:49 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 1YCEvk-0005qg-A3 for gllmg-musl@m.gmane.org; Fri, 16 Jan 2015 22:59:48 +0100 Original-Received: (qmail 28465 invoked by uid 550); 16 Jan 2015 21:59:45 -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 28457 invoked from network); 16 Jan 2015 21:59:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dd-wrt.com; s=mikd; h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:To:MIME-Version:From:Date:Message-ID; bh=kKG6huwYJSh8Q71oXhh8LfC8nZWWcTC+DXgzfooqfpA=; b=tF9wyTS9JfGL0KBJMAiy8+WH0e5mYcoQ9xpzdsSsf7oHOHpmCKgI8OEnvN5vNFQ2uL++ajndBhAi6ZPNaUS6G0foYwcv3ZaJOaSnCCENjD8GQkqPZJcw2fbLIhi+zsed1O9jNTJa2/PJVbDK6q0eIEpVnUISaQvbBqgbQe3IwBw=; User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 In-Reply-To: <20150116180933.GX4574@brightrain.aerifal.cx> X-SA-Exim-Connect-IP: 87.155.240.136 X-SA-Exim-Mail-From: s.gottschall@dd-wrt.com X-Spam-Checker-Version: SpamAssassin 3.1.9 (2007-02-13) on webmail.newmedia-net.de X-Spam-Level: X-Spam-Status: No, score=-2.5 required=4.0 tests=ALL_TRUSTED,BAYES_00, DNS_FROM_AHBL_RHSBL,RATWARE_GECKO_BUILD autolearn=no version=3.1.9, No X-SA-Exim-Version: 4.2.1 (built Thu, 26 May 2011 15:22:33 +0200) X-SA-Exim-Scanned: Yes (on webmail.newmedia-net.de) X-NMN-MailScanner-Information: Please contact the ISP for more information X-NMN-MailScanner-ID: 1YCEvS-0006Tu-Rt X-NMN-MailScanner: Found to be clean X-NMN-MailScanner-From: s.gottschall@dd-wrt.com X-Received: from [87.155.240.136] (helo=[10.88.193.128]) by webmail.newmedia-net.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1YCEvS-0006Tu-Rt for musl@lists.openwall.com; Fri, 16 Jan 2015 22:59:31 +0100 Xref: news.gmane.org gmane.linux.lib.musl.general:6858 Archived-At: Am 16.01.2015 um 19:09 schrieb Rich Felker: > 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. i'm pretty good in finding out such issues, even with the old printf way. will try it with the stats way, even if it will likelly point to a musl libc function. so a stack backtrace would be better to see the caller location > > Rich >