| Summary: | Segfault in debugedit | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] OE-Core | Reporter: | Richard Purdie <richard.purdie> | ||||
| Component: | core | Assignee: | Mark Hatle <mark.hatle> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | Medium+ | CC: | mark.hatle, meta.mr.watcher, meta.watcher | ||||
| Version: | 1.4 | ||||||
| Target Milestone: | 1.4 M6 | ||||||
| Hardware: | x86 | ||||||
| OS: | Multiple | ||||||
| Whiteboard: | |||||||
| OS type for building Yocto: | --- | Type of Regression: | --- | ||||
| Verified: | Documentation change: | --- | |||||
| Attachments: |
|
||||||
|
Description
Richard Purdie
2013-03-24 12:23:05 UTC
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. |