Re: [Info-mtools] segfault in 4.0.29 mcopy

[Alain Knaff]

Hi,

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 
/tmp/mkimage.cEPbHl/image-aa545b554d9d4d9480eab6d0f1edd6ef8b932df4-x86 
/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
/tmp/mkimage.cEPbHl/image-aa545b554d9d4d9480eab6d0f1edd6ef8b932df4-x86 
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
expected?


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

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
> 


Regards,

Alain