From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3384 Path: news.gmane.org!not-for-mail From: plan9assembler Newsgroups: gmane.linux.lib.musl.general Subject: Re: util-linux-2.23 mount segmentation fault error Date: Thu, 30 May 2013 16:26:13 +0900 Message-ID: References: <20130527142929.GF31915@port70.net> <51A60C74.6050500@gentoo.org> <20130529200453.GC7095@port70.net> <20130530064353.GE7095@port70.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7b6d7c1ccd747504ddea6913 X-Trace: ger.gmane.org 1369898788 10235 80.91.229.3 (30 May 2013 07:26:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 30 May 2013 07:26:28 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-3388-gllmg-musl=m.gmane.org@lists.openwall.com Thu May 30 09:26:29 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1UhxFk-0005rt-5M for gllmg-musl@plane.gmane.org; Thu, 30 May 2013 09:26:28 +0200 Original-Received: (qmail 23764 invoked by uid 550); 30 May 2013 07:26:26 -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 23750 invoked from network); 30 May 2013 07:26:26 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=V57zJuyNmhVqT+pmMYDJqwgn4yyl1EBbmiwRP3Ob6OU=; b=WoBD4+nR/PML2Al26x8vPYp8A9zmQCHjHaUoInD5a/KgfrAA7CZYC+8S0u7vJ6Kj1O Q9wvDmuh0lKe7UKINlAavHVwEv1Znv0eiNu73hLhfw00YQHMOCwGbD1MO8yIQVuSv0Gw jdEg9IVMjjPXnxXQtMxG56FpcKUy/DCA4pXIvwIPzme72npjG54bOldU5gUlugZmhqA2 DFDiB0KMEbRPkLuOp2iywGwpc4ZenVuXR9Q0nqpRut5sAzO7H5ZG++7TfC+JB4f1t6lk rqh4gJl8WkSB+yGIPy0n5yo2B8kO6CueUR04wa0GieAPqdvsgbCLbpTNortXW8K2bRQM aYgg== X-Received: by 10.68.106.130 with SMTP id gu2mr4341101pbb.111.1369898773998; Thu, 30 May 2013 00:26:13 -0700 (PDT) In-Reply-To: <20130530064353.GE7095@port70.net> Xref: news.gmane.org gmane.linux.lib.musl.general:3384 Archived-At: --047d7b6d7c1ccd747504ddea6913 Content-Type: text/plain; charset=ISO-8859-1 Hi, thanks for the patch, i tested it. it still gets same segfaults, same bt gdb result. # gdb ./mount /dev/sda1 /mnt r bt and it is clear to me that latest musl libc[2013/05/29] contain new bug, because, below abnormal operation never happened before. (musl version git pulled at 2013/05/03) # ./mount /dev/sda1 /mnt EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null) < 30 - 40 seconds waiting without return to shell> mount: /mnt: filesystem mounted, but mount(8) failedOperation timed out // <-- this is weird. # On Thu, May 30, 2013 at 3:43 PM, Szabolcs Nagy wrote: > * plan9assembler [2013-05-30 15:11:09 +0900]: > > here is backtrace of gdb for "./mount /dev/sda1 /mnt" > > > > Program received signal SIGSEGV, Segmentation fault. > > 0x00007ffff7dd58fb in strlen () from /lib/ld-musl-x86_64.so.1 > > (gdb) at > > #0 0x00007ffff7dd58fb in strlen () from /lib/ld-musl-x86_64.so.1 > > #1 0x00007ffff79614b6 in unmangle_string (s=0x6164732f7665642f
> 0x616732f7665642 out of bounds>) at ./include/mangle.h:17 > > #2 mnt_parse_table_line (s=0x7fffffffe640 "/dev/sda1 /mnt ext4 rw 0 0", > > fs=0x608f00) at libmount/src/tab_parse.c:78 > > #3 mnt_table_parse_next (tb=tb@entry=0x7ffff7ffb360, f=f@entry > =0x608a00, > > fs=fs@entry=0x608f00, filename=filename@entry=0x7ffff7973e78 > "/etc/mtab", > > nlines=nlines@entry=0x7fffffffeab4) at at libmount/src/tab_parse.c:396 > > yes this is the %ms issue i was talking about > > > On Thu, May 30, 2013 at 7:17 AM, plan9assembler < > plan9assembler@gmail.com>wrote: > > > correction: > > > > > > #if 1 > > > #define _IO(a,b) _IOC(0U,(a),(b),0) //? > > > #define _IOW(a,b,c) _IOC(1U,(a),(b),sizeof(c)) //? > > > #else > > > #define _IO(a,b) _IOC(0,(a),(b),0) //ok > > > #define _IOW(a,b,c) _IOC(1,(a),(b),sizeof(c)) //ok > > > #endif > > > > > > #define _IOR(a,b,c) _IOC(2U,(a),(b),sizeof(c)) //ok > > > - #define _IOW(a,b,c) _IOC(3U,(a),(b),sizeof(c)) //ok > > > + #define _IOWR(a,b,c) _IOC(3U,(a),(b),sizeof(c)) //ok > > this does not make sense to me > > > > On Thu, May 30, 2013 at 7:07 AM, plan9assembler < > plan9assembler@gmail.com>wrote: > > >> could you send me the patch? i will test it. > > my super sophisticated patch has no warranty > you could do better parsing or wait for musl to support %ms > > --047d7b6d7c1ccd747504ddea6913 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi, thanks for the patch, i tested it.=

it still gets same segfaults, same bt gdb result.

# gdb ./mount /dev/sda1 /mnt
r
bt

and it is clear to me that latest musl libc[2013/05/29] contain n= ew bug, because,
below abnormal operation never happened before. (= musl version git pulled at 2013/05/03)

# ./mount /dev/sda1 /mnt
EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null)

< 30 - 40  seconds waiting without return to shell>

mount: /mnt: filesystem mounted, but mount(8) failedOperation timed out
// <-- this is weird.
#




On Thu, May 30, 2013 at 3:43 PM, Szabolcs Nagy <nsz@= port70.net> wrote:
* plan9assembler <plan9assembler@gmail.com> [2013-05-30 15:11:09 = +0900]:
> here is backtrace of gdb for "./mount /dev/sda1= /mnt"
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x00007ffff7dd58fb in strlen () from /lib/ld-musl-x86_64.so.1
> (gdb) at
> #0 =A00x00007ffff7dd58fb in strlen () from /lib/ld-musl-x86_64.so.1 > #1 =A00x00007ffff79614b6 in unmangle_string (s=3D0x6164732f7665642f &l= t;Address
> 0x616732f7665642 out of bounds>) at ./include/mangle.h:17
> #2 =A0mnt_parse_table_line (s=3D0x7fffffffe640 "/dev/sda1 /mnt ex= t4 rw 0 0",
> fs=3D0x608f00) at libmount/src/tab_parse.c:78
> #3 =A0mnt_table_parse_next (tb=3Dtb@entry=3D0x7ffff7ffb360, f=3Df@entr= y=3D0x608a00,
> fs=3Dfs@entry=3D0x608f00, filename=3Dfilename@entry=3D0x7ffff7973e78 &= quot;/etc/mtab",
> nlines=3Dnlines@entry=3D0x7fffffffeab4) at at libmount/src/tab_parse.c= :396

yes this is the %ms issue i was talking about

> On Thu, May 30, 2013 at 7:17 AM, plan9assembler <plan9assembler@gmail.com>wrote:
> > correction:
> >
> > #if 1
> > #define _IO(a,b) _IOC(0U,(a),(b),0) =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 //?
> > #define _IOW(a,b,c) _IOC(1U,(a),(b),sizeof(c)) //?
> > #else
> > #define _IO(a,b) _IOC(0,(a),(b),0) =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 //ok
> > #define _IOW(a,b,c) _IOC(1,(a),(b),sizeof(c)) =A0 //ok
> > #endif
> >
> > #define _IOR(a,b,c) _IOC(2U,(a),(b),sizeof(c)) =A0//ok
> > - #define _IOW(a,b,c) _IOC(3U,(a),(b),sizeof(c)) //ok
> > + #define _IOWR(a,b,c) _IOC(3U,(a),(b),sizeof(c)) //ok

this does not make sense to me

> > On Thu, May 30, 2013 at 7:07 AM, plan9assembler <plan9assembler@gmail.com>wrote:
> >> could you send me the patch? i will test it.

my super sophisticated patch has no warranty
you could do better parsing or wait for musl to support %ms


--047d7b6d7c1ccd747504ddea6913--