Hi,
With the LD_SIGNAL=6 setting I failed to get it to create a core file,
so I ran it directly inside the gdb debugger to get the stack trace at
the point of the abort:
------------------------------------------
...
warning: Lowest section in /lib/libdl.so.1 is .dynamic at 00000094
warning: Lowest section in /lib/libpthread.so.1 is .dynamic at 00000074
warning: Lowest section in /usr/lib/lwp/libthread.so.1 is .dynamic at
00000074
Program received signal SIGABRT, Aborted.
0xfefc04d8 in _lwp_kill () from /lib/libc.so.1
(gdb) bt
#0 0xfefc04d8 in _lwp_kill () from /lib/libc.so.1
#1 0xfef5fb1c in raise () from /lib/libc.so.1
#2 0xfef3ff40 in abort () from /lib/libc.so.1
#3 0xfe1c2b7c in Dll::sym(std::string const&) (this=0xff9b8,
s...@0xffbfe530) at Dll.cc:55
#4 0xfe2e06d4 in DbiImpl::create_backend(std::string const&,
std::string const&, std::string const&, std::string const&, std::string
const&, std::string const&, int) (this=0xfe612f70,
usagena...@0xffbfec10, hostna...@0xffbfe8a4,
ty...@0xffbfe8a0, dbna...@0xffbfe8b0, userna...@0xffbfe8a8,
passwo...@0xffbfe8ac, connectionpoolsize=1)
at Dbi.cc:131
#5 0xfe2dfe74 in DbiImpl::create_backend(std::string const&,
std::string const&, int) (this=0xfe612f70,
usagena...@0xffbfec10, xmlfi...@0xffbfea18, connectionpoolsize=1) at
Dbi.cc:102
#6 0xfe2dfac8 in DbiImpl::create_backend(std::string const&, int)
(this=0xfe612f70, usagena...@0xffbfec10,
connectionpoolsize=1) at Dbi.cc:77
#7 0xfe2dfa24 in DbiImpl::create_backend(std::string const&)
(this=0xfe612f70, usagena...@0xffbfec10) at Dbi.cc:64
#8 0xfe3e85b0 in IpSessionResumeDbi::IpSessionResumeDbi()
(this=0xe8588) at libmsmutil/Singleton.h:385
#9 0xfe4423ec in init_session_resume () at ipsession-resume.aatv.cc:32
#10 0xfe442464 in rad_session_resume_start_init (aatvPtr=0xfe498e30) at
ipsession-resume.aatv.cc:46
#11 0x0001be18 in init_aatvs ()
#12 0x000186bc in Dpicdata.picdata ()
(gdb)
------------------------------------------
I also found a core file from a few days ago and did a pstack on it:
------------------------------------------
bash-3.00# pstack core.16367
fefc1d84 __systemcall6 (3, ff252180, 0, 20, 30544, 0) + 24
fefb50dc pthread_sigmask (2, ffbfd830, 0, ff252000, ffff, ffff) + 1b4
fefb510c sigprocmask (2, ffbfd830, 0, 6, ffff0000, 0) + 20
fefacbfc sigrelse (6, 0, 20f90, ff36b7cc, ff38a000, 6) + 54
ff369110 umem_do_abort (1a, ffbfd708, 6, 20ecc, ff37680c, 0) + 30
ff369214 umem_panic (ff377720, 72, 20e3c, ff0dd500, ff38a000, ff37773a)
+ 68
ff36ae7c getpcstack (ffbfddb0, f, 1, 1c, fefbf40c, fa4e0) + 1e0
ff36d7b0 umem_cache_free_debug (78508, f59b0, fa498, feedf800,
feedface, ff38a000) + 1ac
ff36dfec umem_cache_free (78508, f59b0, 3, 1c05c, ff0e6a60, ff38a000) +
50
ff36b214 process_free (f59b8, 1, 0, ff3ec190, 1ee5c, ff0e0994) + 78
ff0eeb14 _ZdlPv (f59b8, ffbfdb74, ff000000, ff000000, 30594,
ff3ec268) + 1c
fe2df9c0 _ZN7DbiImplD1Ev (fe612f68, fffff0c8, 1b0, fffff0cc, 30544,
ff3ec268) + 1e8
fe3a8900
_ZN4Loki15SingletonHolderI7DbiImplNS_12CreateStaticENS_15DefaultLifetime
ENS_14SingleThreadedEE16DestroySingletonEv (ffbfdd50, 1084, 0, 0, 4, 0)
+ 60
fef40728 _exithandle (fefedb40, ff031400, fefecb80, ffbfde00, ffbfde00,
ff2a1528) + 3c
fef2f060 exit (fffffff9, 3, 42898, 42858, 6, ff2a0c8c) + 4
0001d5f8 sig_fatal (6, 0, ffbfdfa0, 0, ff38a000, ffbfdec0) + c4
fefbf418 __sighndlr (6, 0, ffbfdfa0, 1d534, 0, 0) + c
fefb47e8 call_user_handler (6, ffbffeff, 0, 0, ff252000, ffbfdfa0) +
3b8
fefc04d8 _lwp_kill (6, 6, 5, 6, 33834, 0) + 8
fef3ff38 abort (ffbfe318, ffbfe3b8, 0, a8404, 28718, 0) + d0
fe1c2b74 _ZN3Dll3symERKSs (f59b8, ffbfe540, ffbfe648, ffbfe927, ff0000,
80808080) + 2bc
fe2e06cc _ZN7DbiImpl14create_backendERKSsS1_S1_S1_S1_S1_i (fe612f68,
ffbfec20, ffbfe8b4, ffbfe8b0, ffbfe8c0, ffbfe8b8) + 808
fe2dfe6c _ZN7DbiImpl14create_backendERKSsS1_i (fe612f68, ffbfec20,
ffbfea28, 1, 4, 4) + 324
fe2dfac0 _ZN7DbiImpl14create_backendERKSsi (fe612f68, ffbfec20, 1,
fe2df4d8, ff031400, ff031440) + 54
fe2dfa1c _ZN7DbiImpl14create_backendERKSs (fe612f68, ffbfec20,
ffbfed40, 0, 0, 0) + 18
fe3e8568 _ZN18IpSessionResumeDbiC1Ev (e2588, fe612fb0, fe47cba0,
fffff000, fe6131ac, 0) + 34
fe4423a4 init_session_resume (fe498b60, 1, fe47cba0, ffbfef8c,
fe6131ac, 0) + 8
fe44241c rad_session_resume_start_init (fe498e30, fe4423d8, fe47cbb8,
5f736573, 80808080, 1010101) + 4
0001be10 init_aatvs (7, 6b400, 5f800, 1, 0, 632ed) + fc
000186b4 main (632e4, 2020, 0, 6b368, ff250140, ff250180) + 898
00017ca8 _start (0, 0, 0, 0, 0, 0) + 5c
bash-3.00#
------------------------------------------
It also happens without the UMEM_DEBUG variable set.
Best Wishes,
Marc
> -----Original Message-----
> From: mdb-discuss-bounces at opensolaris.org
> [mailto:mdb-discuss-bounces at opensolaris.org] On Behalf Of
> Jonathan W. Adams
> Sent: vrijdag 3 maart 2006 20:26
> To: mdb-discuss at opensolaris.org
> Subject: [mdb-discuss] Re: Libumem problem?
>
> > export LD_PRELOAD=libumem.so
> > export UMEM_DEBUG=default
>
> > When I now run my program I get the following error from
> dlerror when I
> > try to call dlsym in my program:
>
> > ld.so.1: myapp: fatal:
> /usr/platform/SUNW,Ultra-60/lib/libkvm_psr.so.1:
> > open failed: No such file or directory
>
> > Without the LD_PRELOAD the program works perfectly.
> > The error happens at a point in the program where I call dlsym(...).
>
> It looks more like when you call dlopen(). Hrm. You can
> cause ld.so.1(1) to
> use SIGABRT instead of SIGKILL (and therefore get a core
> file) by setting:
> export LD_SIGNAL=6
>
> in the environment; the stack trace (pstack core) which
> results would be most interesting.
>
> libkvm_psr hasn't existed since Solaris 7, so I'm quite
> confused that anything would be
> referencing it.
>
> It's possible that this is some kind of uninitialized data
> problem; does the problem
> disappear if you unset the UMEM_DEBUG environment variable?
>
> Cheers,
> - jonathan
> This message posted from opensolaris.org
> _______________________________________________
> mdb-discuss mailing list
> mdb-discuss at opensolaris.org
>
