attach gdbserver to itself

attach gdbserver to itself

[Bin Chen]

Hi,

Current I am doing a trick that attach the gdbserver to itself when the 
process encounter the segment fault, like this:

void segv_handler(int no)
{
    int pid, status;

    VoIPLog("segv_handler.");
    char buf[128];

    pid = getpid();

    sprintf(buf, "/usr/bin/gdbserver :9988 --attach %d", pid);

    pid = fork();
    if (pid == 0) {
        system(buf);
    } else
        ::wait((int *)&status);

    return;
}

But in most of time this can't get useful information, especially in 
multi threading env, most of time the result is wrong, of course, I am 
saying the backtrace.

But if I start program by gdbserver :9988 program, it can catch the 
error. What is the difference? How can I revise my code to make above 
code has same effect like starting the program by gdbserver?

I am debugging in ARM platform.

Any help appreciated!

Bin Chen

Re: attach gdbserver to itself

[Daniel Jacobowitz]

On Wed, Jan 24, 2007 at 08:48:05PM +0800, Bin Chen wrote:
> But if I start program by gdbserver :9988 program, it can catch the 
> error. What is the difference? How can I revise my code to make above 
> code has same effect like starting the program by gdbserver?

It should work fine.  You need to explain exactly what happens, what
commands you use, and what output you get.

-- 
Daniel Jacobowitz
CodeSourcery

Re: attach gdbserver to itself

[Bin Chen]

Daniel Jacobowitz wrote:
> On Wed, Jan 24, 2007 at 08:48:05PM +0800, Bin Chen wrote:
>   
>> But if I start program by gdbserver :9988 program, it can catch the 
>> error. What is the difference? How can I revise my code to make above 
>> code has same effect like starting the program by gdbserver?
>>     
>
> It should work fine.  You need to explain exactly what happens, what
> commands you use, and what output you get.
>   
Thanks for your quick reply!
Yes, it should :) I just run

target remote board:9988
bt

The source code is large, so I can't paste all the code here. I am 
looking for anyone has similar case...

binch@binary-ubuntu:~/work/Project/code/app_engine/APWifiCtrl$ 
arm_v4t_le-gdb src/wifictrld -x cmd
GNU gdb 6.0 (MontaVista 6.0-11.0.6.0401382 2004-10-08)
Copyright 2003 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=armv4tl-hardhat-linux"...
0x4002c8f0 in ?? ()
(gdb) bt
#0  0x4002c8f0 in wait () from 
/home/binch/work/Project/image/src/docimage/lib/libpthread.so.0
#1  0x0000d680 in segv_handler(int) (no=11) at wifictrld.cpp:88
#2  0x4002b570 in pthread_barrierattr_setpshared () from 
/home/binch/work/Project/image/src/docimage/lib/libpthread.so.0
#3  0x0000d680 in segv_handler(int) (no=-1) at wifictrld.cpp:88
Previous frame inner to this frame (corrupt stack?)
(gdb) quit
The program is running.  Exit anyway? (y or n) y

I also show my cxxflags:

arm_v4t_le-g++ -o wifictrld.o -c -g wifictrld.cpp -O0 -g -pipe -fPIC 
-fno-rtti -fno-exceptions -mapcs-32 -march=armv5te -mtune=arm9e 
-DAPDebug=1 -DDBGLOG=1 -DBGTIME=1 -DEXT_RELEASE=0

Re: attach gdbserver to itself

[Daniel Jacobowitz]

On Wed, Jan 24, 2007 at 08:55:59PM +0800, Bin Chen wrote:
> binch@binary-ubuntu:~/work/Project/code/app_engine/APWifiCtrl$ 
> arm_v4t_le-gdb src/wifictrld -x cmd
> GNU gdb 6.0 (MontaVista 6.0-11.0.6.0401382 2004-10-08)

You're using MontaVista's (modified) version of GDB.  I strongly
recommend you contact them with any problems you may have.

> (gdb) bt
> #0  0x4002c8f0 in wait () from 
> /home/binch/work/Project/image/src/docimage/lib/libpthread.so.0
> #1  0x0000d680 in segv_handler(int) (no=11) at wifictrld.cpp:88
> #2  0x4002b570 in pthread_barrierattr_setpshared () from 
> /home/binch/work/Project/image/src/docimage/lib/libpthread.so.0
> #3  0x0000d680 in segv_handler(int) (no=-1) at wifictrld.cpp:88
> Previous frame inner to this frame (corrupt stack?)

This means that your version of GDB does not support backtracing
through signal handlers - a common problem.  I believe the current
FSF release of GDB (version 6.6) does this better.

-- 
Daniel Jacobowitz
CodeSourcery

Re: attach gdbserver to itself

[Bin Chen]

Daniel Jacobowitz wrote:
> On Wed, Jan 24, 2007 at 08:55:59PM +0800, Bin Chen wrote:
>   
>> binch@binary-ubuntu:~/work/Project/code/app_engine/APWifiCtrl$ 
>> arm_v4t_le-gdb src/wifictrld -x cmd
>> GNU gdb 6.0 (MontaVista 6.0-11.0.6.0401382 2004-10-08)
>>     
>
> You're using MontaVista's (modified) version of GDB.  I strongly
> recommend you contact them with any problems you may have.
>
>   
>> (gdb) bt
>> #0  0x4002c8f0 in wait () from 
>> /home/binch/work/Project/image/src/docimage/lib/libpthread.so.0
>> #1  0x0000d680 in segv_handler(int) (no=11) at wifictrld.cpp:88
>> #2  0x4002b570 in pthread_barrierattr_setpshared () from 
>> /home/binch/work/Project/image/src/docimage/lib/libpthread.so.0
>> #3  0x0000d680 in segv_handler(int) (no=-1) at wifictrld.cpp:88
>> Previous frame inner to this frame (corrupt stack?)
>>     
>
> This means that your version of GDB does not support backtracing
> through signal handlers - a common problem.  I believe the current
> FSF release of GDB (version 6.6) does this better.
>
>   
But I can do get the backtrace if I running the program through 
gdbserver, not dynamic attach when fault.

Anyway, I will try to compile 6.6 to ARM platform, is it supported in 
the release?

Re: attach gdbserver to itself

[Daniel Jacobowitz]

On Wed, Jan 24, 2007 at 09:20:05PM +0800, Bin Chen wrote:
> But I can do get the backtrace if I running the program through 
> gdbserver, not dynamic attach when fault.

That's probably because you aren't inside a called signal handler in
that case.

> Anyway, I will try to compile 6.6 to ARM platform, is it supported in 
> the release?

Yes, but you will have to set solib-absolute-prefix by hand or compile
it using --with-sysroot (see the manual).

-- 
Daniel Jacobowitz
CodeSourcery

Re: attach gdbserver to itself

[Bin Chen]

Daniel Jacobowitz wrote:
> On Wed, Jan 24, 2007 at 09:20:05PM +0800, Bin Chen wrote:
>   
>> But I can do get the backtrace if I running the program through 
>> gdbserver, not dynamic attach when fault.
>>     
>
> That's probably because you aren't inside a called signal handler in
> that case.
>
>   
>> Anyway, I will try to compile 6.6 to ARM platform, is it supported in 
>> the release?
>>     
>
> Yes, but you will have to set solib-absolute-prefix by hand or compile
> it using --with-sysroot (see the manual).
>   

I compiled gdb-6.6 and then successfully run it in board, but the result 
is the same.

gdbserver :9988 prog

can get the backtrace.

but attach to itself can't get the backtrace, anyone encounter similar case?

Re: attach gdbserver to itself

[Bin Chen]

Daniel Jacobowitz wrote:
> On Wed, Jan 24, 2007 at 09:20:05PM +0800, Bin Chen wrote:
>   
>> But I can do get the backtrace if I running the program through 
>> gdbserver, not dynamic attach when fault.
>>     
>
> That's probably because you aren't inside a called signal handler in
> that case.
>
>   
>> Anyway, I will try to compile 6.6 to ARM platform, is it supported in 
>> the release?
>>     
>
> Yes, but you will have to set solib-absolute-prefix by hand or compile
> it using --with-sysroot (see the manual).
>   

I know what happens now. Seems gdb need unstripped libc-2.3.2.so or 
other important libs. The libs in my device rootfs are stripped so it 
can't get the backtrace properly. After changing solib-absolute-prefix 
to another unstripped version , the gdb can work now...

Something weird is that why manully start prog by gdbserver can get the 
right result...