CoreDump -- Cannot access memory

CoreDump -- Cannot access memory

[rdtorres]

Hi all,

First of all sorry to send an email to linuxsh-dev list directly, I
doing it because my attempt to use linux-sh@m17n.org fail (its site is
down).

My problem:
I trying to analyse a core-dump of  "Hello-world" like app that is
running on SH4-STLinux, but it fails.

gdb gives me :

/opt/STM/STLinux-2.2/devkit/sh4/bin/sh4-linux-gdb mysand core
GNU gdb STMicroelectronics/Linux Base 6.4-12 [build Oct 15 2006]
Copyright 2005 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "--host=i686-pc-linux-gnu --target=sh4-linux"...

warning: exec file is newer than core file.
Core was generated by `./mysand'.
Program terminated with signal 6, Aborted.
Reading symbols from
/opt/7109/STM/STLinux-2.2/devkit/sh4/target/usr/lib/libstdc++.so.6...done.
Loaded symbols for
/opt/7109/STM/STLinux-2.2/devkit/sh4/bin/../target/usr/lib/libstdc++.so.6
Reading symbols from
/opt/7109/STM/STLinux-2.2/devkit/sh4/target/lib/libm.so.6...done.
Loaded symbols for
/opt/7109/STM/STLinux-2.2/devkit/sh4/bin/../target/lib/libm.so.6
Reading symbols from
/opt/7109/STM/STLinux-2.2/devkit/sh4/target/lib/libgcc_s.so.1...done.
Loaded symbols for
/opt/7109/STM/STLinux-2.2/devkit/sh4/bin/../target/lib/libgcc_s.so.1
Reading symbols from
/opt/7109/STM/STLinux-2.2/devkit/sh4/target/lib/libc.so.6...done.
Loaded symbols for
/opt/7109/STM/STLinux-2.2/devkit/sh4/bin/../target/lib/libc.so.6
Reading symbols from
/opt/7109/STM/STLinux-2.2/devkit/sh4/target/lib/ld-linux.so.2...done.
Loaded symbols for
/opt/7109/STM/STLinux-2.2/devkit/sh4/bin/../target/lib/ld-linux.so.2
#0  0x297382d4 in raise () from
/opt/7109/STM/STLinux-2.2/devkit/sh4/bin/../target/lib/libc.so.6
(gdb) bt full
#0  0x297382d4 in raise () from
/opt/7109/STM/STLinux-2.2/devkit/sh4/bin/../target/lib/libc.so.6
No symbol table info available.
#1  0x29739dd6 in abort () from
/opt/7109/STM/STLinux-2.2/devkit/sh4/bin/../target/lib/libc.so.6
No symbol table info available.
Cannot access memory at address 0x7b916ff8



My program code:

#include <stdlib.h>

extern void m1();

static int count = 0;

void m3(){
       if (count++ > 2)
               abort();
       m1();
}

void m2(){
       m3();
}

void m1 (){
       m2();
}

int
main (int argc, char* argv[]) {
       m1();
       return 0;
}

I compiled it with /opt/STM/STLinux-2.2/devkit/sh4/bin/sh4-linux-g++
-g -o mysand sandbox.cpp

I've tried -fstack-protector-all option without success too.

Before running it on STLinux I'm running: ulimited -c unlimited.


Do you have any idea why the stack of my core-dump is broken ?

Ps. Note that the memory address is a huge address ( 0x7b916ff8 ).


Thanks in advance,
Rafael Torres

Re: CoreDump -- Cannot access memory

[Paul Pluzhnikov]

On Wed, Oct 1, 2008 at 2:32 PM,  <rdtorres@gmail.com> wrote:

> Before running it on STLinux I'm running: ulimited -c unlimited.
> Do you have any idea why the stack of my core-dump is broken ?

The two common reasons I've seen:
- core is truncated.
- mismatch between /opt/7109/STM/STLinux-2.2/devkit/sh4/target/lib/libc.so.6
  that you see on host, and what is actually used on the target.

Note that 'ulimit -c unlimited' does not guarantee that you have
a complete core: you could run into filesystem limit for example.

> Ps. Note that the memory address is a huge address ( 0x7b916ff8 ).

I am not familiar with SH, but the high value does not appear to
be unreasonable for a stack address.

Cheers,

P.S. If you have (or can build) a gdbserver for the target, you
might want to use that instead of core.

-- 
Paul Pluzhnikov

Re: CoreDump -- Cannot access memory

[Mark Kettenis]

> Date: Wed, 1 Oct 2008 18:32:14 -0300
> From: rdtorres@gmail.com
> 
> Do you have any idea why the stack of my core-dump is broken ?

Probably because the core dump was truncated.  Usually that happens
because you're running with ulimit -c set to a value that's too small.