[haiku-development] Re: Jamming in debugging info?
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Tue, 14 Jul 2009 16:16:50 +0200
On 2009-07-14 at 09:37:11 [+0200], pete.goodeve@xxxxxxxxxxxx wrote:
[...]
> Unfortunately though, Ingo's suggestion of
> > readelf --debug-dump=decodedline <file>
> doesn't do anything at all, except tell me that "decodedline" is an
> unrecognized option. (Not in the man page, either.)
It's apparently an option introduced with version 2.19. "=line" works in
earlier version, but produces less nice output.
[...]
> With the new information, I've been able to establish exactly
> where the fault is hit, but it hasn't helped much! It seems to be
> cleanup code after the closing brace of an if-then-else block, but
> I've no idea what gets done for that. The instruction that triggers
> it is "mov 0x4(%ecx, %edx"), with ecx containing 0xccccccc, so it
> bombs on an access of 0xccccccd0, but I can't really follow the
> route it takes to get there.
That 0xcc pattern is written into fresh allocations by the heap allocator.
Encountering it like this usually means that some field in an allocated
structure has not been initialized.
> Is this something that should get a specific ticket? I could paste
> the code involved, or relevant parts, there.
Yes, please create a ticket. Please attach the kernel stack trace and the
disassembled code for the function in question.
CU, Ingo
Other related posts:
