> > On Mon, 6 Mar 2006, Michael Shapiro wrote: > > > Typically there are two reasons for seeing something like this: > > > > - a stripped binary or stripped loadable object > > - a loadable object which has been dlclose()d > > > > Is it possible you're hitting one of these cases? One thing you can > > quickly check is to do: > > > > <addr>$m > > > > which will tell you what mapping the address is in. If you get an answer > > from that, then it may be stripped. If you don't, then that address > > refers to something which wasn't in memory anymore. > > Hi Mike, > > When I run $m on the address, I get the following: > > > 0x10085f2a0$m > BASE LIMIT SIZE NAME > 100800000 10090e000 10e000 > > I also ran file against the executable and each library linked into the > executable, and they all show up as "ELF 64-bit MSB dynamic lib SPARCV9 > Version 1, dynamically linked, not stripped." Given this info, is there a > way to determine the function name for the topmost function in the stack > backtrace? > > Thanks for the reply, > - Ryan
Hmm: as you see there is no NAME for that mapping, so this is why you're not getting any symbols: we didn't match it to an object file. Can you send back the entire $m output? -Mike -- Mike Shapiro, Solaris Kernel Development. blogs.sun.com/mws/
