mailing list of musl libc
 help / color / mirror / code / Atom feed
From: plan9assembler <plan9assembler@gmail.com>
To: musl@lists.openwall.com
Subject: Re: util-linux-2.23 mount segmentation fault error
Date: Sun, 2 Jun 2013 08:16:47 +0900	[thread overview]
Message-ID: <CAGSZau2GYnsGzKAa1WoYwTXKZcny=_r4wdNmdtbivhM3FUupbA@mail.gmail.com> (raw)
In-Reply-To: <CAGSZau1+wWXG3zX0DhRguQhdLmqAQp=kXC4DZt+GRaYrmkJ0sQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2319 bytes --]

ah! util-linux umount gets segfault always.


On Sun, Jun 2, 2013 at 8:14 AM, plan9assembler <plan9assembler@gmail.com>wrote:

> Hi,
>
> latest musl libc seems to fixes mount segfault error partially.
> (mount: /mnt: filesystem mounted, but mount(8) failedOperation timed out)
> rebuild and test vanilla util-linux-2.23 result same.
> tested util-linux-2.23.1 same.
> tested gcc-4.8.1 same.
>
> sscanf "%ms" -> "%s" with malloc doesn't fixed the issue here.
> with patch or without it result same.
>
> i compile strace-4.7 to trace the bug, but get some build error:
> gcc -Wall -Wwrite-string -g -O2 -o strace strace.o syscall.o count.o
> util.o desc.o file.o ipc.o io.o ioctl.o mem.o net.o process.o bjm.o quota.o
> resource.o signal.o sock.o system.o term.o time.o scsi.o stream.o block.o
> pathtrace.o mtd.o vsprintf.o loop.o
> syscall.o:(.rodata+0x28080): undefined reference to `sys_getdents64'
> syscall.o:(.rodata+0x2b100): undefined reference to `sys_truncate64'
> syscall.o:(.rodata+0x2b118): undefined reference to `sys_ftruncate64'
> syscall.o:(.rodata+0x2b388): undefined reference to `sys_getdents64'
> syscall.o:(.rodata+0x2dd00): undefined reference to `sys_getdents64'
>
> BTW, i was quite surprised by base packages are so much "glibc-centric"..
>
>
>
> On Thu, May 30, 2013 at 5:37 PM, Szabolcs Nagy <nsz@port70.net> wrote:
>
>> * plan9assembler <plan9assembler@gmail.com> [2013-05-30 16:26:13 +0900]:
>> >
>> > it still gets same segfaults, same bt gdb result.
>> >
>>
>> if you get the exact same segfault then you do something wrong
>> ..or malloc(200) is not enough
>>
>> > 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.
>> > #
>>
>> works here fine
>> since you have local modifications i'd check those first
>>
>> i doubt that latest musl has any related bug
>>
>> but you could easily prove me wrong with a strace
>> that shows bad flags passed to some syscall
>>
>>
>

[-- Attachment #2: Type: text/html, Size: 3443 bytes --]

  reply	other threads:[~2013-06-01 23:16 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-25 15:46 plan9assembler
2013-05-25 16:26 ` Rich Felker
2013-05-25 21:34   ` plan9assembler
2013-05-26  9:14     ` Szabolcs Nagy
2013-05-26 11:22       ` plan9assembler
2013-05-27 14:05         ` plan9assembler
2013-05-27 14:29           ` Szabolcs Nagy
2013-05-27 21:40             ` plan9assembler
2013-05-29 13:46               ` plan9assembler
2013-05-29 14:11               ` Luca Barbato
2013-05-29 14:32                 ` plan9assembler
2013-05-29 14:41                   ` plan9assembler
2013-05-29 20:04                     ` Szabolcs Nagy
2013-05-29 22:07                       ` plan9assembler
2013-05-29 22:17                         ` plan9assembler
2013-05-30  6:11                           ` plan9assembler
2013-05-30  6:43                             ` Szabolcs Nagy
2013-05-30  7:26                               ` plan9assembler
2013-05-30  8:37                                 ` Szabolcs Nagy
2013-06-01 23:14                                   ` plan9assembler
2013-06-01 23:16                                     ` plan9assembler [this message]
2013-06-02  1:50                                     ` John Spencer
2013-06-02 10:55                                       ` plan9assembler
2013-06-02 13:00                                         ` Szabolcs Nagy
2013-06-02 22:02                                           ` plan9assembler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAGSZau2GYnsGzKAa1WoYwTXKZcny=_r4wdNmdtbivhM3FUupbA@mail.gmail.com' \
    --to=plan9assembler@gmail.com \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).