Created attachment 1133 [details] Binary which causes a segfault in debugedit If we build qemuppc on an x86-64 machine, there are segfaults occuring during do_package coming from debugedit. Unfortunately the code has not been catching the error condition and continuing regardless. Attached binary triggers the segfault with the command '/media/build1/poky/build/tmp/sysroots/x86_64-linux/usr/lib/rpm/bin/debugedit' -b '/media/build1/poky/build/tmp/work/ppc603e-poky-linux' -d '/usr/src/debug' -i -l '/media/build1/poky/build/tmp/work/ppc603e-poky-linux/libgcc/4.7.2-r19/debugsources.list' '/media/build1/poky/build/tmp/work/ppc603e-poky-linux/libgcc/4.7.2-r19/package/lib/libgcc_s.so.1' Note that once it has faulted, the command modifies the binary and won't fault a second time, you need to revert to a clean copy of the binary. If we remove the -i option, the segfault does not occur. The fault occurs in handle_build_id() which consists with this. GDB Session: richard@dax:/media/build1/poky/build$ gdb '/media/build1/poky/build/tmp/sysroots/x86_64-linux/usr/lib/rpm/bin/debugedit' GNU gdb (GDB) 7.5-ubuntu Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /media/build1/poky/build/tmp/sysroots/x86_64-linux/usr/lib/rpm/bin/debugedit...done. (gdb) r -b '/media/build1/poky/build/tmp/work/ppc603e-poky-linux' -d '/usr/src/debug' -i -l '/media/build1/poky/build/tmp/work/ppc603e-poky-linux/libgcc/4.7.2-r19/debugsources.list' '/media/build1/poky/build/tmp/work/ppc603e-poky-linux/libgcc/4.7.2-r19/package/lib/libgcc_s.so.1' Starting program: /media/build1/poky/build/tmp/sysroots/x86_64-linux/usr/lib/rpm/bin/debugedit -b '/media/build1/poky/build/tmp/work/ppc603e-poky-linux' -d '/usr/src/debug' -i -l '/media/build1/poky/build/tmp/work/ppc603e-poky-linux/libgcc/4.7.2-r19/debugsources.list' '/media/build1/poky/build/tmp/work/ppc603e-poky-linux/libgcc/4.7.2-r19/package/lib/libgcc_s.so.1' [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. 0x00007ffff72f06f0 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 (gdb) bt #0 0x00007ffff72f06f0 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x00007ffff7bc3257 in sha1Update () from /media/build1/poky/build/tmp/sysroots/x86_64-linux/usr/lib/rpm/bin/../../../../usr/lib/libbeecrypt.so.7 #2 0x0000000000402a63 in process (size=<optimised out>, data=<optimised out>) at /media/build1/poky/build/tmp/work/x86_64-linux/rpm-native/5.4.9-r61/rpm-5.4.9/tools/debugedit.c:1435 #3 handle_build_id (build_id_size=20, build_id_offset=16, build_id=0x608908, dso=0x60a390) at /media/build1/poky/build/tmp/work/x86_64-linux/rpm-native/5.4.9-r61/rpm-5.4.9/tools/debugedit.c:1484 #4 main (argc=<optimised out>, argv=<optimised out>) at /media/build1/poky/build/tmp/work/x86_64-linux/rpm-native/5.4.9-r61/rpm-5.4.9/tools/debugedit.c:1673
I'm able to reproduce the problem. No idea as to the cause yet.
More info: When processing the buildid, it gets to sections 23/24: [23] .plt NOBITS 000239e4 0139e4 000234 00 WAX 0 0 4 [24] .bss NOBITS 00023c18 0139e4 0001c8 00 WA 0 0 8 This is returning a load address of '0', but a size. When attempting to md5sum the chunk, it can't read the address starting at 0. Still unknown why this is happening.
I'd note I have patches to fix do_package's error checking. I'm holding off those until we get the segfault fixed though as once merged, qemuppc builds will simply fail packaging entirely.
I similarly have patches. All mine do is capture the result of the subprocess.call commands for debugedit as well as objcopy. Then if the ret != 0, we do a bb.error and return non-zero. (But my patches don't seem to do anything w/ the non-zero return code.. so that would still have to be done.) This should definitely cause a failure, and not fail silently.
I've looked at the code some more. It does checksum the header itself and then if it's got contents, it also adds the contents to the checksum.. That is where the failure appears to be happening: if (u.shdr.sh_type != SHT_NOBITS) { Elf_Data *d = elf_rawdata (dso->scn[i], NULL); if (d == NULL) goto bad; process (d->d_buf, d->d_size); } So it's specifically checking for SHT_NOBITS, but it's matching so it falls through and d->d_buf == 0, causing the failure. I'll keep investigating, but somehow that value (u.shdr.sh_type) is wrong [or at least unexpected!].
Workaround was committed: oe-core: a046029eb96cd9307253937ceeadafaaa6d06dce
I have identified the problem. The sh_type is not being swapped to the native endian of the host. So the values are wrong. i.e. [1] - type 0x7000000 should be 0x7 [2] - type 0xf6ffff6f should be 0x6ffffff6 ... [23] - type 0x8000000 should be 0x8 ...
A fix for this issue was sent to the oe-core mailing list.