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
>>
>>
>