[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Info-mtools] segfault in 4.0.29 mcopy

From: Alain Knaff
Subject: Re: [Info-mtools] segfault in 4.0.29 mcopy
Date: Mon, 7 Jun 2021 12:24:17 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0


On 07/06/2021 10:40, Natanael Copa wrote:
> Hi,
> I am about to make a release candidate of alpine linux 3.14, but bumped into 
> a segfault on 32 bit x86:
> Here is the backtrace:
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from /usr/bin/mcopy...
> Reading symbols from /usr/lib/debug//usr/bin/mtools.debug...
> warning: core file may not match specified executable file.
> [New LWP 7584]
> Core was generated by `mcopy -i 
> /tmp/mkimage.cEPbHl/image-aa545b554d9d4d9480eab6d0f1edd6ef8b932df4-x86'.
Is this the full command line?

If so, it is strange that this is even getting that far, as for me it 
results in a usage output, due to absence of source and destination.

However, the following works ok here

./mcopy -i 
/etc/issue ::
./mcopy -i 
/tmp/mkimage.cEPbHl/image-aa545b554d9d4d9480eab6d0f1edd6ef8b932df4-x86 ::issue .

So, in order to allow me to reproduce this, please send me the full 
command line, and all other relevant state (such as contents of
image file, if crash depends on state of that file). Or, alternatively, 
if file too large, the steps needed to create it.

> Program terminated with signal SIGSEGV, Segmentation fault.
> #0  0x566013d2 in force_read (Stream=0xf7ee4711 <get_stride+5>, 
> buf=0xffc7a08c "", start=0, len=512) at force_io.c:61
This one is weird. There is no symbol get_stride mentioned anywhere in mtools.

I wonder where this is coming from?

On the other hand, it might be worthwhile comparing this with what shows 
at this point in 4.0.28 (or 4.0.27) (by putting a breakpoint in 
force_read). Maybe this symbol somehow comes from musl libc, and is

> 61              return force_io(Stream, buf, start, len,
> (gdb) bt
> #0  0x566013d2 in force_read (Stream=0xf7ee4711 <get_stride+5>, 
> buf=0xffc7a08c "", start=0, len=512) at force_io.c:61
> #1  0x56601c6c in read_boot (size=512, boot=0xffc7a08c, Stream=<optimized 
> out>) at init.c:50
Ok, so it was an optimized compile. However, even with -O8, I still 
couldn't reproduce this here.

Did you use any other compilation flags which might help me reproduce 

Another weird thing is that the read_boot parameters are in a different 
order than what is in the 4.0.29 sources...

Again, comparing this with a build of a previous mtools, might be 
helpful here too, maybe the musl libc toolchain changes order of 
function parameters in some cases?

> #9  0x5660602e in mcopy (argc=5, argv=0xffc7bff4, mtype=0) at mcopy.c:615

ok, so 5 arguments where indeed given => good.

But a short command history leading up to this might still be helpful :-)

> #10 0x565faab2 in main (argc=<optimized out>, argv=0xffc7bff4) at mtools.c:184
> (gdb) 
> Note that this is built with musl libc.

Where can I get musl libc from most easily, and how to use it (i.e. 
./configure and make command lines)

> I was not able to find any public git repository to investigate the change 
> history.
> -nc



reply via email to

[Prev in Thread] Current Thread [Next in Thread]