On 04/27/10 13:32, Darryl Gove 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>
Should be:
bcheck -all <app> <params>
[bcheck is a wrapper for dbx.]
Darryl.
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
