named crashes on assertion in rbtdb.c on sparc64/SMP

[KOT MATPOCKuH]

2011/7/7 Marius Strobl <marius at alchemy.franken.de>:
> That's not the patch I was referring to. I did a second one which just
> entirely disables the use of atomic operations on sparc64:
> http://people.freebsd.org/~marius/sparc64_isc_disable_atomic.diff
Omg. I'm sorry.
I applied this patch and restarted named, but named crashed immediatly
after start:
08-Jul-2011 15:29:54.631 found 2 CPUs, using 2 worker threads
08-Jul-2011 15:29:54.633 using up to 4096 sockets
Segmentation fault (core dumped)

core's backtrace:
#0  0x0000000040953ba8 in __sparc_utrap_install () from /lib/libc.so.7
(gdb) bt
#0  0x0000000040953ba8 in __sparc_utrap_install () from /lib/libc.so.7
#1  0x0000000040953ccc in __sparc_utrap_install () from /lib/libc.so.7
#2  0x0000000040953f70 in __sparc_utrap_install () from /lib/libc.so.7
#3  0x00000000409537ac in __sparc_utrap_install () from /lib/libc.so.7
#4  0x00000000407c2d54 in pthread_mutex_lock () from /lib/libthr.so.3
#5  0x0000000000228dcc in ?? ()
Previous frame identical to this frame (corrupt stack?)

Could this be a sign to a problem in libthr?

PS.
Also one month ago I got a problems with another multithreaded
application from ports (www/oops). oops was crashed with stack's
backtrace:
#0  0x0000000040d8fc88 in __sparc_utrap_install () from /lib/libc.so.7
#1  0x0000000040d8fdac in __sparc_utrap_install () from /lib/libc.so.7
#2  0x0000000040d90050 in __sparc_utrap_install () from /lib/libc.so.7
#3  0x0000000040d8f88c in __sparc_utrap_install () from /lib/libc.so.7
#4  0x0000000040d64044 in _malloc_thread_cleanup () from /lib/libc.so.7
#5  0x0000000040c039b8 in fork () from /lib/libthr.so.3
#6  0x0000000040c03d38 in fork () from /lib/libthr.so.3
#7  0x0000000040c03f50 in pthread_exit () from /lib/libthr.so.3
#8  0x0000000040c04414 in pthread_detach () from /lib/libthr.so.3
#9  0x0000000040c04710 in pthread_create () from /lib/libthr.so.3

But on yesterday's world's build oops works properly. I think it may
be related to r223228 (?)
Or I incorrectly analyze stack for multithreaded applications?

-- 
MATPOCKuH