"(gdb) run" crash when running executables on qemu emulated arm architecture

Question

I'm going through a course on gdb. In the later lessons the course covers debugging on ARM architecture, so I'm presented a setup that allows me to emulate such situation.

My current setup comprises:

• Windows 10: physical host
  • Ubuntu 12.04.5 LTS: guest os via Oracle Virtual Box on Windows 10
    • Linux debian-armel 2.6.32-5-versatile: guest os via qemu 2.8.0 on Ubuntu

The ARM Debian image comes from https://people.debian.org/~aurel32/qemu/armel/

The image is launched with

qemu-system-arm -M versatilepb -kernel vmlinuz-2.6.32-5-versatile -initrd initrd.img-2.6.32-5-versatile -hda debian_squeeze_armel_standard.qcow2 -append "root=/dev/sda1" -m 256 -redir tcp:2222::22

I modified the sources.list and apt.conf to allow apt to work, since the distro is quite outdated. I updated and upgraded and installed gcc and gdb.

The problem arises when trying to debug; I can load executables in gdb:

root@debian-armel:~/video-11/video-11# file ./main
./main: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not stripped

but when I try to run it inside gdb, I receive this message and the execution hangs, until I'm able to kill the gdb process from another console:

------------[ cut here ]------------
WARNING: at /build/linux-2.6-fIxTVd/linux-2.6-2.6.32/debian/build/source_armel_none/kernel/sched.c:2628 wake_up_process+0x2c/0x48()
Modules linked in: loop sg smc91x sr_mod mii cdrom psmouse evdev ext3 jbd mbcache sd_mod crc_t10dif sym53c8xx scsi_transport_spi scsi_mod
[<c002b068>] (unwind_backtrace+0x0/0xdc) from [<c0046f88>] (warn_slowpath_common+0x4c/0x80)
[<c0046f88>] (warn_slowpath_common+0x4c/0x80) from [<c00446f0>] (wake_up_process+0x2c/0x48)
[<c00446f0>] (wake_up_process+0x2c/0x48) from [<c0026930>] (arch_ptrace+0x214/0x4bc)
[<c0026930>] (arch_ptrace+0x214/0x4bc) from [<c00508d8>] (sys_ptrace+0x9c/0x164)
[<c00508d8>] (sys_ptrace+0x9c/0x164) from [<c0024ec0>] (ret_fast_syscall+0x0/0x28)
---[ end trace 98ab50bc781b314f ]---

How can I resolve this issue?

Answer 1

Not my answer, but to enable the question to be marked as closed:

This is likely a bug in the guest kernel (though not certainly so), so I would start by trying with a more recent kernel than 2.6.32, which is now nearly 8 years old. – Peter Maydell Mar 3 '17 at 13:14