attach gdbserver to itself

Thread: attach gdbserver to itself

Search this list only Search all lists
attach gdbserver to itself
	2007-01-24 06:48:05

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
	2007-01-24 06:51:41

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
	2007-01-24 06:55:59

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... binchbinary-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
	2007-01-24 07:05:10

On Wed, Jan 24, 2007 at 08:55:59PM +0800, Bin Chen wrote: > binchbinary-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
	2007-01-24 07:20:05

Daniel Jacobowitz wrote: > On Wed, Jan 24, 2007 at 08:55:59PM +0800, Bin Chen wrote: > >> binchbinary-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
	2007-01-24 07:27:06

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
	2007-01-24 20:12:01
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
	2007-01-24 20:28:47
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...

[1-8]

about | contact Other archives ( Real Estate discussion Medical topics )