Core dump in __mutex_alloc_int with 4.7.25 on Solaris 10

Question

I'm a newbie to the forum and to BDB. I'm not a database person either.
I build BDB 4.7.25 and run the test suite (run_all) - it passes a large portion but fails in Env007 after echoing "Env007.h: -create -thread".
I have not yet applied 3 patches for this version but before I go do that please tell me if I'm likely wasting my time or not - I see a number of seemingly disparaging remarks in the source code about Solaris. I see a number of threads close to my issue but nothing on target so far - pardon me if I missed an obvious, on-target thread.
I'm using gcc-3.4.6 from www.sunfreeware.com.
I used this configure command
CC=gcc \
../dist/configure \
--enable-compat185 \
--enable-pthread_api \
--enable-rpc \
--enable-tcl \
--enable-test
Then I start tclsh8.4, source ../test/test.tcl, and execute a test. Here is the stack backtrace from just running Env007:
(gdb) bt
#0 0xfee4e774 in __mutex_alloc_int () from /spadmin/build/db-4.7.25.NC/build_unix/.libs/libdb_tcl-4.7.so
#1 0xfee4f2f4 in __mutex_open () from /spadmin/build/db-4.7.25.NC/build_unix/.libs/libdb_tcl-4.7.so
#2 0xfee9934c in __env_open () from /spadmin/build/db-4.7.25.NC/build_unix/.libs/libdb_tcl-4.7.so
#3 0xfee5fc44 in __env_setup () from /spadmin/build/db-4.7.25.NC/build_unix/.libs/libdb_tcl-4.7.so
#4 0xfee7f1fc in __db_open () from /spadmin/build/db-4.7.25.NC/build_unix/.libs/libdb_tcl-4.7.so
#5 0xfee79f70 in __db_open_pp () from /spadmin/build/db-4.7.25.NC/build_unix/.libs/libdb_tcl-4.7.so
#6 0xfedafb6c in bdb_DbOpen () from /spadmin/build/db-4.7.25.NC/build_unix/.libs/libdb_tcl-4.7.so
#7 0xfedb1950 in berkdb_Cmd () from /spadmin/build/db-4.7.25.NC/build_unix/.libs/libdb_tcl-4.7.so
#8 0xff2a73b8 in TclEvalObjvInternal () from /usr/local/lib/libtcl8.4.so
#9 0xff2a7c74 in Tcl_EvalEx () from /usr/local/lib/libtcl8.4.so
#10 0xff2a811c in Tcl_EvalObjEx () from /usr/local/lib/libtcl8.4.so
#11 0xff2ac988 in Tcl_EvalObjCmd () from /usr/local/lib/libtcl8.4.so
#12 0xff2a73b8 in TclEvalObjvInternal () from /usr/local/lib/libtcl8.4.so
#13 0xff2ccc90 in TclExecuteByteCode () from /usr/local/lib/libtcl8.4.so
#14 0xff2cc270 in TclCompEvalObj () from /usr/local/lib/libtcl8.4.so
#15 0xff2fdbd4 in TclObjInterpProc () from /usr/local/lib/libtcl8.4.so
#16 0xff2a73b8 in TclEvalObjvInternal () from /usr/local/lib/libtcl8.4.so
#17 0xff2a7c74 in Tcl_EvalEx () from /usr/local/lib/libtcl8.4.so
#18 0xff2a811c in Tcl_EvalObjEx () from /usr/local/lib/libtcl8.4.so
#19 0xff2ac988 in Tcl_EvalObjCmd () from /usr/local/lib/libtcl8.4.so
#20 0xff2a73b8 in TclEvalObjvInternal () from /usr/local/lib/libtcl8.4.so
#21 0xff2ccc90 in TclExecuteByteCode () from /usr/local/lib/libtcl8.4.so
#22 0xff2cc270 in TclCompEvalObj () from /usr/local/lib/libtcl8.4.so
#23 0xff2fdbd4 in TclObjInterpProc () from /usr/local/lib/libtcl8.4.so
#24 0xff2a73b8 in TclEvalObjvInternal () from /usr/local/lib/libtcl8.4.so
#25 0xff2ccc90 in TclExecuteByteCode () from /usr/local/lib/libtcl8.4.so
#26 0xff2cc270 in TclCompEvalObj () from /usr/local/lib/libtcl8.4.so
#27 0xff2a8140 in Tcl_EvalObjEx () from /usr/local/lib/libtcl8.4.so
#28 0xff2d9fcc in Tcl_RecordAndEvalObj () from /usr/local/lib/libtcl8.4.so
#29 0xff2eee04 in Tcl_Main () from /usr/local/lib/libtcl8.4.so
#30 0x000107e0 in main ()
(gdb)
Looking at what the patches do I am inclined to think they are not going to address this. But while awaiting a reply I will start that.
Can anyone say for certain that 4.7.25 can be built and be enterprise class quality with gcc on Solaris 10 [08/07 right now]?
Do I need different configure options?
What else do I need to know?
Many Thanks in Advance

Answer 1

The test has gotten as far as rep036 with zero FAILures but it appears to be deadlocked:
[160]} ptree 26166
3818 /usr/local/sbin/sshd
23791 /usr/local/sbin/sshd -R
23793 /usr/local/sbin/sshd -R
23795 -ksh
26166 tclsh
7627 /usr/local/bin/tclsh8.4
11898 /usr/local/bin/tclsh8.4 ../dist/../test/wrap.tcl rep036script
11900 /usr/local/bin/tclsh8.4
11899 /usr/local/bin/tclsh8.4 ../dist/../test/wrap.tcl rep036script
11901 /usr/local/bin/tclsh8.4
[161]} truss -aefl -rall -vall -wall -p 7627
7627/1: psargs: /usr/local/bin/tclsh8.4
7627/1: lwp_cond_wait(0xFE902AD0, 0xFE902AB8, 0x00000000, 0) (sleeping...)
7627/1: condvar type: USYNC_PROCESS
7627/1: mutex type: USYNC_PROCESS
[162]} truss -aefl -rall -vall -wall -p 11898
11898/1: psargs: /usr/local/bin/tclsh8.4 ../dist/../test/wrap.tcl rep036script.tc
11898/1: waitid(P_PID, 11900, 0xFFBFEA30, WEXITED|WTRAPPED) (sleeping...)
[163]} truss -aefl -rall -vall -wall -p 11900
11900/1: psargs: /usr/local/bin/tclsh8.4
11900/1: pollsys(0xFFBFE480, 0, 0xFFBFE4E8, 0x00000000) = 0
11900/1: timeout: 1.000500000 sec
11900/1: pollsys(0xFFBFE480, 0, 0xFFBFE4E8, 0x00000000) = 0
11900/1: timeout: 1.000500000 sec
11900/1: pollsys(0xFFBFE480, 0, 0xFFBFE4E8, 0x00000000) = 0
11900/1: timeout: 1.000500000 sec
11900/1: pollsys(0xFFBFE480, 0, 0xFFBFE4E8, 0x00000000) = 0
11900/1: timeout: 1.000500000 sec
11900/1: pollsys(0xFFBFE480, 0, 0xFFBFE4E8, 0x00000000) (sleeping...)
11900/1: timeout: 1.000500000 sec
11900/1: pollsys(0xFFBFE480, 0, 0xFFBFE4E8, 0x00000000) = 0
11900/1: timeout: 1.000500000 sec
11900/1: pollsys(0xFFBFE480, 0, 0xFFBFE4E8, 0x00000000) = 0
11900/1: timeout: 1.000500000 sec
[164]} truss -aefl -rall -vall -wall -p 11899
11899/1: psargs: /usr/local/bin/tclsh8.4 ../dist/../test/wrap.tcl rep036script.tc
11899/1: waitid(P_PID, 11901, 0xFFBFEA30, WEXITED|WTRAPPED) (sleeping...)
[165]} truss -aefl -rall -vall -wall -p 11901
11901/1: psargs: /usr/local/bin/tclsh8.4
11901/1: lwp_cond_wait(0xFE902C60, 0xFE902C48, 0x00000000, 0) (sleeping...)
11901/1: condvar type: USYNC_PROCESS
11901/1: mutex type: USYNC_PROCESS
^C[166]}
as it has not produced any further output in the last 2 hours. Off to reconfigure as recommended now - I guess my experience suggests this mutex mechanism isn't quite ready for prime time.