Very Computer

by **cmcnau..** » Fri, 13 May 2005 22:15:28

Been trying to track down corrupted malloc'd area on an old application
running under Solaris 2.6 and using xview. The application Bus Errors
with an invalid address alignment when a pointer in a malloc'd area
used by a trusted area of the code is corrupted by (I think) 3rd party
map generation software in another part of the application.
Using WATCHMALLOC I have found and corrected 10 coding errors which
could have caused the problem (writing outside the malloc'd area) but
on the latest run got all the way back to the same Bus Error without
being trapped by WATCHMALLOC. The core file shows the hex value
0xdeadbeef in the corrupted pointer (and other memory locations)
although previous to the coding error fixes I've seen a 0x1 in the
corrupted area. I'm looking for some advice on what to do next. No
reference to 'deadbeef' in the application code. Any idea on where it
may originate or any advice on further debugging?
BTW each run under WATCHMALLOC takes about 6 hours.
Colin McNaught

by **Thomas Maier-Komo** » Fri, 13 May 2005 22:38:55

> Been trying to track down corrupted malloc'd area on an old application
> running under Solaris 2.6 and using xview. The application Bus Errors
> with an invalid address alignment when a pointer in a malloc'd area
> used by a trusted area of the code is corrupted by (I think) 3rd party
> map generation software in another part of the application.
> Using WATCHMALLOC I have found and corrected 10 coding errors which
> could have caused the problem (writing outside the malloc'd area) but
> on the latest run got all the way back to the same Bus Error without
> being trapped by WATCHMALLOC. The core file shows the hex value
> 0xdeadbeef in the corrupted pointer (and other memory locations)
> although previous to the coding error fixes I've seen a 0x1 in the
> corrupted area. I'm looking for some advice on what to do next. No
> reference to 'deadbeef' in the application code. Any idea on where it
> may originate or any advice on further debugging?
> BTW each run under WATCHMALLOC takes about 6 hours.
> Colin McNaught

0xdeadbeef means the block has already been free'ed. Did you consider
running the application on a Solaris 9 machine with libumem. AFAIK
it is faster and offers more functionality than watchmalloc. See man
umem_debug for an explanation.

Tom

by **cmcnau..** » Sat, 14 May 2005 00:05:58

Thanks, I should read the man pages more carefully....
Solaris 9 is not an option at this time unfortunately. Ploughing on...
Colin

Very Computer

deadbeef malloc corrupted heap, etc.

deadbeef malloc corrupted heap, etc.

deadbeef malloc corrupted heap, etc.

deadbeef malloc corrupted heap, etc.