|
From: Naveen K. <g_n...@ya...> - 2005-02-17 15:02:19
|
well what you could do is find the process mapping
just before it dumped core. I usually insert a {
while(1) sleep(5); } at that point. You can then look
at proc/[pid]/map to find out which object is loaded
around that address. Once you find that you can use
elfdump or some other tool to find out what
function/instruction this failed at. I do this if
loading the symbol-file for the object doesn't work
with gdb(no debugging symbols found).
Naveen
--- Nicholas Nethercote <nj...@cs...> wrote:
> On Tue, 15 Feb 2005, Jeremy Fitzhardinge wrote:
>
> > "x/i $eip" will show you the faulting instuction;
> from that you can
> > determine the effective address it was trying to
> access. You can get
> > register values with "print $<reg>".
>
> I get the following
>
> [~/grind/head2] gdb coregrind/valgrind core
> GNU gdb 5.3
> [...]
> This GDB was configured as "i686-pc-linux-gnu"...
> Core was generated by
> `/u/njn/grind/head2/coregrind/valgrind date'.
> Program terminated with signal 11, Segmentation
> fault.
> #0 0xb805ab88 in ?? ()
> (gdb) x/i $eip
> 0xb805ab88: Cannot access memory at address
> 0xb805ab88
>
> Does that mean it jumped to an address that had no
> underlying mapping?
>
> N
>
>
>
-------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT
> Products from real users.
> Discover which products truly live up to the hype.
> Start reading now.
>
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Valgrind-developers mailing list
> Val...@li...
>
https://lists.sourceforge.net/lists/listinfo/valgrind-developers
>
__________________________________
Do you Yahoo!?
The all-new My Yahoo! - Get yours free!
http://my.yahoo.com
|