Hi!
----
This is slightly offtopic, but due lack of a dbx-related mailinglist and
because it happens while debugging ksh93 I am dropping it here for now:
While trying to debug ksh93 with "check -leaks" and/or "check -memuse"
dbx (version "Sun Dbx Debugger 7.4 117845-01 2005/03/05") simply crashes
like this:
-- snip --
% env - SHELL=$SHELL TERM=$TERM HOME=$HOME EDITOR=$EDITOR
/opt/onbld/bin/bldenv ./opensolaris.sh
# build the OS/Net B37 tree where ksh93 has been integrated
% cd /home/test001/ksh93/on_build1/test1/usr/src/lib/libshell
# run dbx like this:
% (LD_LIBRARY_PATH=$ROOT/lib dbx ../../cmd/ksh/i386/ksh)
(dbx) check -memuse
(dbx) run -o emacs
run -o emacs
Running: ksh -o emacs
(process id 19500)
Reading rtcapihook.so
Reading libdl.so.1
Reading rtcaudit.so
Reading libmapmalloc.so.1
Reading libgen.so.1
Reading rtcboot.so
Reading librtc.so
RTC: Enabling Error Checking...
dbx: can't find a system call entry point -- program not linked with
libc?
dbx: internal error: signal SIGSEGV (no mapping at the fault address)
dbx's coredump will appear in /tmp
dbx: internal warning: BptMgr::bpt_takeout. bpt 0xb81761d0 not in bpt
list
Abort (core dumped)
-- snip --
Uhm... OK... something went horribly wrong with dbx... ;-(
The contents of the core dump look like this:
-- snip --
% echo "where" | dbx /opt/SUNWspro/bin/dbx /tmp/core
For information about new features see `help changes'
To remove this message, put `dbxenv suppress_startup_message 7.4' in
your .dbxrc
Reading dbx
core file header read successfully
Reading ld.so.1
Reading libintl.so.1
Reading libnsl.so.1
Reading libsocket.so.1
Reading libdl.so.1
Reading libgen.so.1
Reading libw.so.1
Reading libm.so.1
Reading libc.so.1
Reading libcpc.so.1
Reading libpctx.so.1
Reading libnvpair.so.1
Reading libproc.so.1
Reading librtld_db.so.1
Reading libelf.so.1
Reading libctf.so.1
Reading libmp.so.2
Reading libmd5.so.1
Reading libscf.so.1
Reading libuutil.so.1
Reading libc_db.so.1
program terminated by signal ABRT (Abort)
0xd2e18c07: __lwp_kill+0x0007: jae __lwp_kill+0x15 [
0xd2e18c15, .+0xe ]
=>[1] __lwp_kill(0x1, 0x6), at 0xd2e18c07
[2] _pthread_kill(0x1, 0x6), at 0xd2e160a2
[3] raise(0x6), at 0xd2dddff9
[4] abort(0xd2e619a0, 0x8046b08, 0xd2e5e000, 0x0, 0x0, 0x0), at
0xd2dc01e4
[5] 0x80f2259(0xb, 0x8046d68, 0x8046b68), at 0x80f2258
[6] __sighndlr(0xb, 0x8046d68, 0x8046b68, 0x80f208c), at 0xd2e17fbf
---- called from signal handler with signal 11 (SIGSEGV) ------
[7] RegSet::getl(0x0, 0x83e01dc), at 0x82c0965
[8] RetRegs::getl(0x8046e40), at 0x81a914c
[9] RtcMgr::call_rtc_init(0x845baa0, 0x87e5940, 0x0, 0x0, 0x8046ef4,
0x82030fc), at 0x81aecd7
[10] RtcMgr::rtc_new_process(0x845baa0), at 0x81abaa6
[11] RtcMgr::try_rtc_new_process(0x845baa0), at 0x81aa9f8
[12] 0x81aa6c9(0x8463390, 0x8725140, 0x0), at 0x81aa6c8
[13] 0x80fc18c(0x88f24f0, 0x8463390, 0x88f1fc0, 0x8725140, 0x1), at
0x80fc18b
[14] ActionList_execute(0x88f1550, 0x8463390, 0x88f1fc0, 0x8725140,
0x1), at 0x80fa840
[15] Handler::decision_procedure(0x88f1fc0, 0x8463390), at 0x816954c
[16] Recognizer::trigger(0x88f1fc0, 0x8463390), at 0x81a68f9
[17] Recognizer::dispatch(0x8373f98, 0x8463390), at 0x81a6d74
[18] Proc::vcpu_dispatch(0x8463390, 0x8479998), at 0x819cd1b
[19] Proc::pervcpu_dispatch(0x8463390, 0x83a7f80), at 0x819cec9
[20] Proc::generic_dispatch(0x8463390, 0x83a7f80), at 0x819d4ab
[21] Proc::go(0x8463390, 0x83a7f80, 0x1, 0x1), at 0x819d968
[22] do_run(0x845d678, 0x0, 0x1), at 0x8178ad6
[23] 0x8178dbd(0x845d678, 0x3, 0x8724df0, 0x0), at 0x8178dbc
[24] 0x825945b(0x845d678, 0x84639f8, 0x8724cc8, 0x8724df0, 0x0), at
0x825945a
[25] pdksh_execute(0x845d678, 0x84639f8, 0x0), at 0x825868d
[26] pdksh_shell(0x845d678, 0x84637c8), at 0x824ad43
[27] main_cmd_loop(0x845d678), at 0x80f5153
[28] main(0x2, 0x804733c, 0x8047348), at 0x80f5d86
-- snip --
My guess is that this is partially the result that there is a "custom"
libc (build from B37 sources on a B37 system - in theory this should be
no difference - but in reality it seems to matter... somehow... ;-( )
... a quick look at the "ldd" output shows this:
-- snip --
% (LD_LIBRARY_PATH=$ROOT/lib ldd /opt/SUNWspro/bin/dbx)
libintl.so.1 =>
/home/test001/ksh93/on_build1/test1/proto/root_i386/lib/libintl.so.1
libnsl.so.1 =>
/home/test001/ksh93/on_build1/test1/proto/root_i386/lib/libnsl.so.1
libsocket.so.1 =>
/home/test001/ksh93/on_build1/test1/proto/root_i386/lib/libsocket.so.1
libdl.so.1 =>
/home/test001/ksh93/on_build1/test1/proto/root_i386/lib/libdl.so.1
libgen.so.1 =>
/home/test001/ksh93/on_build1/test1/proto/root_i386/lib/libgen.so.1
libw.so.1 =>
/home/test001/ksh93/on_build1/test1/proto/root_i386/lib/libw.so.1
libm.so.1 => /lib/libm.so.1
libc.so.1 =>
/home/test001/ksh93/on_build1/test1/proto/root_i386/lib/libc.so.1
libmp.so.2 =>
/home/test001/ksh93/on_build1/test1/proto/root_i386/lib/libmp.so.2
libmd5.so.1 =>
/home/test001/ksh93/on_build1/test1/proto/root_i386/lib/libmd5.so.1
libscf.so.1 =>
/home/test001/ksh93/on_build1/test1/proto/root_i386/lib/libscf.so.1
libuutil.so.1 =>
/home/test001/ksh93/on_build1/test1/proto/root_i386/lib/libuutil.so.1
libm.so.2 => /lib/libm.so.2
-- snip --
I then removed all duplicate libraries that dbx only uses those binaries
shipped on the B37 DVD, resulting in the following "ldd" output:
-- snip --
% (LD_LIBRARY_PATH=$ROOT/lib ldd /opt/SUNWspro/bin/dbx)
libintl.so.1 => /lib/libintl.so.1
libnsl.so.1 => /lib/libnsl.so.1
libsocket.so.1 => /lib/libsocket.so.1
libdl.so.1 =>
/home/test001/ksh93/on_build1/test1/proto/root_i386/lib/libdl.so.1
libgen.so.1 => /lib/libgen.so.1
libw.so.1 => /lib/libw.so.1
libm.so.1 => /lib/libm.so.1
libc.so.1 => /lib/libc.so.1
libmp.so.2 => /lib/libmp.so.2
libmd5.so.1 => /lib/libmd5.so.1
libscf.so.1 => /lib/libscf.so.1
libuutil.so.1 => /lib/libuutil.so.1
libm.so.2 => /lib/libm.so.2
-- snip --
Finally I tried to re-run dbx like this:
-- snip --
% (LD_LIBRARY_PATH=$ROOT/lib dbx ../../cmd/ksh/i386/ksh)
For information about new features see `help changes'
To remove this message, put `dbxenv suppress_startup_message 7.4' in
your .dbxrc
Reading ksh
Reading ld.so.1
Reading libshell.so.1
Reading libast.so.1
Reading libsecdb.so.1
Reading libm.so.2
Reading libc.so.1
Reading libcmd.so.1
Reading libdll.so.1
Reading libsocket.so.1
Reading libnsl.so.1
(dbx) check -leaks
leaks checking - ON
(dbx) run -o emacs
Running: ksh -o emacs
(process id 19535)
Reading rtcapihook.so
Reading libdl.so.1
Reading rtcaudit.so
Reading libmapmalloc.so.1
Reading libgen.so.1
Reading rtcboot.so
Reading librtc.so
RTC: Enabling Error Checking...
signal SEGV (no mapping at the fault address) in evfind at 0xc710d4fa
0xc710d4fa: evfind+0x003a: movl (%eax,%edx,4),%eax
dbx: Stopped within call to '__rtc_init'. Starting new command
interpreter
(dbx) exit
-- snip --
... and again no success... ;-(
Does anyone have a suggestion what I can do at this point to get "dbx"'s
"check -leaks / -memuse" functionality working on i386 ?
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
