bcheck is broken since a year or longer, it only works for simple test cases but not for applications like firefox or ksh. On Opensolaris B134 I get this dump:
bcheck -V bcheck : Sun Dbx Debugger 7.6 SunOS_i386 2007/05/03 bcheck -all /usr/bin/amd64/ksh -c 'print hello' Reading ksh Reading ld.so.1 Reading rtcapihook.so Reading libc.so.1 Reading libdl.so.1 Reading rtcaudit.so Reading libmapmalloc.so.1 Reading libgen.so.1 Reading libm.so.2 Reading rtcboot.so Reading librtc.so access checking - ON memuse checking - ON Running: ksh -c "print hello" (process id 3861) RTC: Enabling Error Checking... RTC: Running program... Reading disasm.so terminating signal 11 SIGSEGV pstack core core 'core' of 3861: /usr/bin/amd64/ksh -c print hello fffffd7fee6128a8 _ti_critical () fffffd7fff3e3dda audit_symbind () + 42 fffffd7fff3e059b elf_bndr () + 1e3 fffffd7fff3c4f93 elf_rtbndr () + 83 fffffd7fff380030 ???????? () Olga On Tue, Apr 27, 2010 at 10:32 PM, Darryl Gove <darryl.g...@oracle.com> wrote: > You might try discover > http://cooltools.sunsource.net/discover/ > to test for memory access errors. > > Or runtime checking in dbx > dbx bcheck -all <app> <params> > > Regards, > > Darryl. > > On 04/27/10 12:06, Jens Elkner wrote: >> >> Hi, >> >> I'm currently getting strange SEGVs from malloc on a UltraSPARC-IIIi >> (V440) >> (see below), no matter whether src is compiled with -m32 or -m64. >> Especially >> with -m64 and even -xmemalign=1i alignment errors seem to happen >> frequently. >> [Hmmm - 'til today I thought, at least 1i gets rid of all alignment errors >> (Compiler is SS12u1).] >> >> Problem source is sendmails libmilter: >> >> http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/sendmail/libmilter/engine.c >> >> http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/sendmail/libmilter/comm.c >> >> 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)); >> (dbx) where >> 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 =>[7] dec_argv(buf = 0x88459 "i", len >> = 68U), line 1764 in "engine.c" >> [8] st_macros(g = 0xfd6fbe90), line 1481 in "engine.c" >> [9] mi_engine(ctx = 0x81630), line 405 in "engine.c" >> [10] mi_handle_session(ctx = 0x81630), line 45 in "handler.c" >> [11] mi_thread_handle_wrapper(arg = 0x81630), line 579 in "listener.c" >> >> >> t...@470 (l...@470) terminated by signal SEGV (no mapping at the fault >> address) >> 0xff2570a8: t_splay+0x0010: ld [%o2 + 8], %o1 >> Current function is mi_rd_cmd >> 143 buf = malloc(expl); >> (dbx) where >> current thread: t...@470 >> [1] t_splay(0x85f14, 0x7f730, 0x31313638, 0x841f8, 0x0, 0x0), at >> 0xff2570a8 [2] t_delete(0x85f14, 0x1fc, 0x31313638, 0xff256f30, >> 0xff3303a8, 0x61696c5f), at 0xff256f30 [3] realfree(0x85d10, 0x1ff, >> 0xd98dc, 0x82c48, 0x0, 0x85d50), at 0xff256b44 [4] cleanfree(0x0, 0xd, >> 0xd902c, 0x0, 0xff3303a8, 0xff3392a4), at 0xff2573cc [5] >> _malloc_unlocked(0x8, 0xb0, 0x80550, 0x80558, 0xffffffff, 0x0), at >> 0xff256524 [6] malloc(0x1, 0x1, 0xd9fd8, 0xff2baaec, 0xff3303a8, >> 0xff33a518), at 0xff256414 =>[7] mi_rd_cmd(sd = 13, timeout = 0xfe3fbe88, >> cmd = 0xfe3fbea7 "D\xff\xff\xff\xfe", rlen = 0xfe3fbec8, name = 0x65730 >> "ClamAV"), line 143 in "comm.c" >> [8] mi_engine(ctx = 0x84350), line 315 in "engine.c" >> [9] mi_handle_session(ctx = 0x84350), line 45 in "handler.c" >> [10] mi_thread_handle_wrapper(arg = 0x84350), line 579 in "listener.c" >> >> >> Is anybody able to spot, what's going wrong here? >> Thanx, >> jel. >> >> "OT": Problem with mail filters, which use libmilter is, that they die >> more or less frequently and thus their results (if any) are ignored >> by >> sendmail. Good thing is, that SMF takes care to restart the >> filter, however those filters are more or less unreliable since they >> do a ~ 90:10 job, only ... :( > > -- > Darryl Gove > Compiler Performance Engineering > Blog : http://blogs.sun.com/d/ > Books: http://www.sun.com/books/catalog/solaris_app_programming.xml > http://my.safaribooksonline.com/0595352510 > _______________________________________________ > opensolaris-code mailing list > opensolaris-code@opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/opensolaris-code > -- , _ _ , { \/`o;====- Olga Kryzhanovska -====;o`\/ } .----'-/`-/ olga.kryzhanov...@gmail.com \-`\-'----. `'-..-| / Solaris/BSD//C/C++ programmer \ |-..-'` /\/\ /\/\ `--` `--` _______________________________________________ opensolaris-code mailing list opensolaris-code@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
