Re: [Qemu-devel] [Bug 1404690] [NEW] Qemu crashes with chrooted m68k

[Peter Maydell]

On 21 December 2014 at 16:21, Michel Boaventura
<address@hidden> wrote:
> Everything works fine. I can run bash, busybox, ash, but when I try to
> run a ls or just type an invalid command, I got the attached sequence of
> messages, which end like so:
>
> 11351 waitpid(-1,0xf6fffa00,0x3) = -1 errno=10 (No child processes)
> qemu: fatal: Illegal instruction: 0000 @ f6fffa30
> D0 = ffffffff   A0 = f67dcf50   F0 = 0000000000000000 (           0)
> D1 = 0000000a   A1 = f66e0898   F1 = 0000000000000000 (           0)
> D2 = f6fffaa8   A2 = f67df268   F2 = 0000000000000000 (           0)
> D3 = 00000000   A3 = 00000000   F3 = 0000000000000000 (           0)
> D4 = 00000008   A4 = 800026c4   F4 = 0000000000000000 (           0)
> D5 = 00000000   A5 = f67d98e0   F5 = 0000000000000000 (           0)
> D6 = f6fffaa8   A6 = f6fffa7c   F6 = 0000000000000000 (           0)
> D7 = 00000002   A7 = f6fffa24   F7 = 0000000000000000 (           0)
> PC = f6fffa30   SR = 0000 ----- FPRESULT =            0
> Aborted
>
> How can I debug it further to try to figure out if this is a qemu issue
> or not? Thanks

This is almost certainly a QEMU bug -- m68k/Coldfire is
unmaintained upstream right now.

I would start debugging this with QEMU's -d and -D options:
you can use "-d in_asm,exec,cpu -D logfile.out" to write
a lot of logging information about the guest code QEMU executes.
(This can be a huge volume, so best to use the shortest possible
reproducing command. Take out 'exec' if it's really too slow.)
Then you can see what the code the guest executed was and figure
out what happened. Alternatively you can try using qemu's
debug stub: pass QEMU "-g 1234" and then connect a coldfire gdb
using gdb's "target remote :1234" command. Either way, what you
want to find out is what exactly happened in the instructions
between the waitpid and the crash.

My current guess is that either we've messed up the waitpid
(seems unlikely, it's not very complicated), or we're not
getting signal handling right (much more complicated and
likely to have bugs): your crash happens at about the point
where the shell is due to receive a SIGCHLD for the child
process it spawned. If you send the shell a signal in some
other way (eg type ctrl-C at it, or send it a SIGINT from
outside QEMU) does it die in a similar way?

PS: an easier way to enable strace for linux-user in a binfmt-misc
chroot is to use the QEMU_STRACE environment variable. (All the
linux-user command line options have environment variable versions;
check --help.)

You can also just use a command like
  'chroot my-chroot /usr/bin/qemu-m68k-static -strace /bin/sh -c /bin/ls'
for a one-off command run.

-- PMM