At 01:20 PM 8/16/2002 -0500, Dan Nelson wrote:
>Make sure you've got the latest patchkit installed. The latest for 5.1
>was released on May 8, and is available at
Dan,
Sorry for the delay in getting back to you, it's taken nearly a week
to rebuild a new 4.0.2 library with the debug options. I had earlier tried
too many builds with the native Compaq compiler and GCC and my development
environment was all mangled (lesson learned: Never try to use GNU ar to
build a library of C++ modules compiled with the Compaq C++ compiler).
Anyway, as for patchkits, that is a bit out of my control. I'm doing
all of this work on the Compaq Test Drive servers in their lab, so I'm at
the mercy of whatever patchkits they have installed. But I assume their
systems are reasonably up to date.
>I assume wsd is your binary? Not sure why it couldn't get the function
>name. Try building mysqld again with --with-debug, and build your
>application with debugging (-g) as well. That should make the stack
>dump even more readable.
Yes, wsd is my binary. I was finally able to get a new 4.0.2
libmysqld library built with the --with-debug option and as you suspected
it did add a lot of detail to the stack dump. Here is a new stack dump
from the same command I was trying in previous tests:
>0 0x3ff8057d728 in __nxm_thread_kill(0x3ffc01842c8, 0x6, 0x1, 0x1, 0x14,
0x3ff
c0184000) in /usr/shlib/libpthread.so
#1 0x3ff80576560 in pthread_kill(0x3ffc01842c8, 0x6, 0x1, 0x1, 0x14,
0x3ffc0184
000) in /usr/shlib/libpthread.so
#2 0x3ff80581ae8 in UnknownProcedure2FromFile99(0x3ffc01842c8, 0x6, 0x1,
0x1, 0
x14, 0x3ffc0184000) in /usr/shlib/libpthread.so
#3 0x3ff807e3aa0 in UnknownProcedure16FromFile0(0x3ffc01842c8, 0x6, 0x1,
0x1, 0
x14, 0x3ffc0184000) in /usr/shlib/libexc.so
#4 0x3ff807e3e90 in exc_raise_signal_exception(0x3ffc01842c8, 0x6, 0x1,
0x1, 0x
14, 0x3ffc0184000) in /usr/shlib/libexc.so
#5 0x3ff80578040 in UnknownProcedure282FromFile0(0x3ffc01842c8, 0x6, 0x1, 0x1,
0x14, 0x3ffc0184000) in /usr/shlib/libpthread.so
#6 0x3ff800d5270 in __sigtramp(0x3ffc01842c8, 0x6, 0x1, 0x1, 0x14,
0x3ffc018400
0) in /usr/shlib/libc.so
#7 0x3ff8057d728 in __nxm_thread_kill(0x3ffc01842c8, 0x6, 0x1, 0x1, 0x14,
0x3ff
c0184000) in /usr/shlib/libpthread.so
#8 0x3ff80576560 in pthread_kill(0x3ffc01842c8, 0x6, 0x1, 0x1, 0x14,
0x3ffc0184
000) in /usr/shlib/libpthread.so
#9 0x3ff8058da08 in UnknownProcedure6FromFile108(0x3ffc01842c8, 0x6, 0x1, 0x1,
0x14, 0x3ffc0184000) in /usr/shlib/libpthread.so
#10 0x3ff8013b0b4 in __tis_raise(0x3ffc01842c8, 0x6, 0x1, 0x1, 0x14,
0x3ffc01840
00) in /usr/shlib/libc.so
#11 0x3ff8019f570 in raise(0x3ffc01842c8, 0x6, 0x1, 0x1, 0x14,
0x3ffc0184000) in
/usr/shlib/libc.so
#12 0x3ff801c2800 in abort(0x3ffc01842c8, 0x6, 0x1, 0x1, 0x14,
0x3ffc0184000) in
/usr/shlib/libc.so
#13 0x3ff801c22b0 in __assert(0x3ffc01842c8, 0x6, 0x1, 0x1, 0x14,
0x3ffc0184000)
in /usr/shlib/libc.so
#14 0x120167280 in vio_read(vio=0x140081700,
buf=0x140892000="\377z\004Table \'w
sd.wsd_user_prefs\' doesn\'t exist", size=4) "lib_vio.c":118
#15 0x120179444 in my_real_read(net=0x140046220, complen=0x11fffad30)
"net_serv.
cc":533
#16 0x12017994c in my_net_read(net=0x140046220) "net_serv.cc":694
#17 0x120170f90 in net_safe_read(mysql=0x140046220) "libmysqld.c":95
#18 0x120172460 in read_rows(mysql=0x140046220, mysql_fields=0x0, fields=5)
"lib
mysqld.c":620
#19 0x12017411c in mysql_read_query_result(mysql=0x140046220)
"libmysqld.c":1163
#20 0x120174600 in mysql_real_query(mysql=0x140046220,
query=0x14005c980="select
userid,prefid,prefvalue from wsd_user_prefs where userid=\'\'",
length=66) "lib
mysqld.c":1284
#21 0x120173ec8 in mysql_query(mysql=0x140046220, query=0x14005c980="select
user
id,prefid,prefvalue from wsd_user_prefs where userid=\'\'") "libmysqld.c":1116
#22 0x120140e90 in select_db_fields(0x3ffc01842c8, 0x6, 0x1, 0x1, 0x14,
0x3ffc01
84000) in wsd
With the additional detail provided, it was obvious that one problem
was that the database hadn't actually been created yet (earlier attempts at
creating and initializing the database had also crashed, with similar
coredumps, so later tests were done with the shorter test that also
crashed). So I ran the install program (wsd-install) that initializes the
database, and it crashed in a similar location:
>0 0x3ff8057d728 in __nxm_thread_kill(0x3ffc01842c8, 0xb, 0x1, 0x1, 0x14,
0x3ff
c0184000) in /usr/shlib/libpthread.so
#1 0x3ff80576560 in pthread_kill(0x3ffc01842c8, 0xb, 0x1, 0x1, 0x14,
0x3ffc0184
000) in /usr/shlib/libpthread.so
#2 0x3ff80581ae8 in UnknownProcedure2FromFile99(0x3ffc01842c8, 0xb, 0x1,
0x1, 0
x14, 0x3ffc0184000) in /usr/shlib/libpthread.so
#3 0x3ff807e3aa0 in UnknownProcedure16FromFile0(0x3ffc01842c8, 0xb, 0x1,
0x1, 0
x14, 0x3ffc0184000) in /usr/shlib/libexc.so
#4 0x3ff807e3e90 in exc_raise_signal_ex
14, 0x3ffc0184000) in /usr/shlib/libexc.so
#5 0x3ff80578040 in UnknownProcedure282
0x14, 0x3ffc0184000) in /usr/shlib/libpthread.so
#6 0x3ff800d5270 in __sigtramp(0x3ffc01842c8, 0xb, 0x1, 0x1, 0x14,
0x3ffc018400
0) in /usr/shlib/libc.so
#7 0x1200cd720 in vio_read() "lib_sql.cc":6
#8 0x1200d9910 in _Z12my_real_readP6st_netPm() "net_serv.cc":6
#9 0x1200da0a0 in my_net_read() "net_serv.cc":6
#10 0x1200ce9cc in net_safe_read() "libmysqld.c":6
#11 0x1200cf358 in read_rows() "libmysqld.c":6
#12 0x1200d06c4 in mysql_read_query_result() "libmysqld.c":6
#13 0x1200d1f74 in mysql_query() "libmysqld.c":6
#14 0x120098f90 in query_db(0x1408e8000, 0x1408e8000, 0x4, 0x0, 0x0, 0xa)
in wsd
-install
#15 0x120091e64 in load_database(0x1408e8000, 0x1408e8000, 0x4, 0x0, 0x0,
0xa) i
n wsd-install
#16 0x120094f50 in process_install(0x1408e8000, 0x1408e8000, 0x4, 0x0, 0x0,
0xa)
in wsd-install
#17 0x120095440 in main(0x1408e8000, 0x1408e8000, 0x4, 0x0, 0x0, 0xa) in
wsd-ins
tall
#18 0x120087a18 in __start(0x1408e8000, 0x1408e8000, 0x4, 0x0, 0x0, 0xa) in
wsd-
install
So it seems as if the UnknownProcedure issue is only a result of not
having debugging information for the signal libraries, and unrelated to the
true cause, which appears to be a fatal error in vio_read.
Any ideas on where I can look next?
Best Regards,
Randall Severy
Randall Severy severy@stripped http://www.cyberteams.com/severy
CyberTeams, Inc. info@stripped http://www.cyberteams.com
Frederick, MD
(301) 682-8885 "Building effective teams in cyberspace"
1-888-832-5575
