[ksh93-integration-discuss] Re: Slightly offtopic: Another way to assasinate dbx (e.g. % (LD_LIBRARY_PATH=$ROOT/lib dbx ... #) ...
Leonard Li
Leonard.Li at Sun.COM
Mon Jun 5 14:04:50 PDT 2006
Hi Roland,
RTC is depended on libc.so for various reason. In this case, it tries to
locate an special instruction (lcall, sysenter or syscall) but fail to
find one. A workaround is to include functions like close(),
sigpending() or setuid() in your customized libc and make sure one of
these instructions is used in those functions.
-Leonard
Roland Mainz wrote On 06/03/06 17:45,:
>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
>
>
>
More information about the ksh93-integration-discuss
mailing list