>Sun has "watchmalloc.so.1" that will SIGTRAP when an >unallocated memory area >is written. However, this is not the case. > >I'm now getting a slightly different output in the debugger and I'm >wondering, why the filename is so long:
>=>[7] vdiaginit(traceflag = , dumpflag = , vtracename = knltrace >\xfe\xca\xd >d\xba\xfe\xca\xdd\xba\xfe\xca\xdd\xba\xfe\xca\xdd\xba\xfe\xca\x vtracename is a char [256] which is supposed to be padded with blanks (see variable vdumpname). One reason for this display could be that the variable isn't properly padded, but that doesn't explain why malloc is getting confused. I suggest that you write a small routine that allocates memory of various sizes and frees them in a different order. If this routines triggers a core when it is called before the fwrite, then it can be used as a check that the heap is still working. Add calls to this routine before the calls of the backtrace to get nearer to the statement where the heap gets corrupted. > [11] Trace_Manager::CreateInstance(TaskId = 1), line 149 in >"Trace_Manager.cpp" Hint: iview.pl Trace_Manager.cpp will find that file and load it into the editor, so yout don't have to 'find' for it. Daniel Dittmar -- Daniel Dittmar SAP Labs Berlin [EMAIL PROTECTED] -- MaxDB Discussion Mailing List For list archives: http://lists.mysql.com/maxdb To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
