On Wed, Apr 28, 2010 at 01:54:58AM +0200, Jens Elkner wrote: > On Tue, Apr 27, 2010 at 12:40:41PM -0700, johan...@opensolaris.org wrote: > > On Tue, Apr 27, 2010 at 09:06:46PM +0200, Jens Elkner wrote: > > > t...@150 (l...@150) terminated by signal SEGV (no mapping at the fault > > > address) > > > 0xff2570a8: t_splay+0x0010: ld [%o2 + 8], %o1 > > > Current function is dec_argv > > > 1764 s = (char **)malloc((nelem + 1) * (sizeof *s)); > > > current thread: t...@150 > > > [1] t_splay(0x85a04, 0x0, 0x1fffff, 0x85808, 0x0, 0xff337480), at > > > 0xff2570a8 > > > [2] t_delete(0x85a04, 0x1fc, 0x1fffff, 0xff256f30, 0xff3303a8, 0x0), at > > > 0xff256f30 > > > [3] realfree(0x85800, 0x1ff, 0xd98dc, 0x8b7a0, 0x0, 0x8a768), at > > > 0xff256b44 > > > [4] cleanfree(0x0, 0xe, 0xd902c, 0x0, 0xff3303a8, 0xff3392a4), at > > > 0xff2573cc > > > [5] _malloc_unlocked(0x28, 0x0, 0x0, 0x0, 0xfffffffc, 0x0), at > > > 0xff256524 > > > [6] malloc(0x24, 0x1, 0xd9fd8, 0x0, 0xff3303a8, 0xff33a518), at > > > 0xff256414 > ... > > > Is anybody able to spot, what's going wrong here? > > > > This looks like a classic case of heap corruption. You've died in > > t_splay while trying to coalese free blocks before performing an > > allocation. Sometimes this happens when an object is double-free'd, > > when you free an object that wasn't allocated by the allocator, or other > > similar mistakes. > > Direct hit! Found it in the milter code (i.e. not in libmilter as > assumed): a struct was malloced but one char* member was overseen when > initializing it (not set to NULL). So in the cleanup function of the > milter the chaos started: if (cf->helo) free(cf->helo); > > > Can you run this application under libumem? It has a bunch of debugging > > features that might help you out here. > > > > This is what I typically use when trying to debug heap corruption. What > > follows is for a 32-bit application. Omit the _32 if you're 64-bit. > > > > LD_PRELOAD_32=libumem.so > > UMEM_DEBUG='audit=50,guards,contents' > > UMEM_LOGGING='transaction,fail,contents' > > > > export LD_PRELOAD_32 UMEM_DEBUG UMEM_LOGGING > > > > HTH, > > Yes - really, really cool stuff! dbx pointed immediately to the line shown > above. Everything else was a matter of 5 minutes. Have it running on two > machines now for about 2.5 hours without any problem!
You may want to check out some of my blog entries regarding libumem: http://blogs.sun.com/wfiveash/entry/playing_with_solaris_memory_debuggers http://blogs.sun.com/wfiveash/entry/update_on_playing_with_solaris http://blogs.sun.com/wfiveash/entry/more_about_libumem -- Will Fiveash Oracle Note my new work e-mail address: will.five...@oracle.com http://opensolaris.org/os/project/kerberos/ Sent using mutt, a sweet text based e-mail app: http://www.mutt.org/ _______________________________________________ opensolaris-code mailing list opensolaris-code@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
