RE: GDB receives SIGKILL

["Vadim Shmelev" <vadim dot shmelev at acronis dot com>]

Thanks for comments, Michael. Below I try to comment your comments.

> 
> (gdb) handle SIG32 nostop noprint
> Signal        Stop      Print   Pass to program Description
> SIG32         No        No      Yes             Real-time event 32
> (gdb) handle SIG33 nostop noprint
> Signal        Stop      Print   Pass to program Description
> SIG33         No        No      Yes             Real-time event 33

Why did you do the above?  Those signals are part of 
linuxthreads handling and debugging.  There should be 
no need to silence them -- if there is, it could be a 
sign of something wrong.

-COMMENT-------------------------------------------------------------
If I enable SIG32 and SIG33 gdb will be stopped at every thread switch.
-END COMMENT---------------------------------------------------------

> 
> (gdb) b
> 'ComputerManagement::CreateLocalLinuxHardwareInfo(Fomatik::Computer*)'
> Breakpoint 1 at 0x9053fe6: file
../../../include/processor/ref/allocator.h,
> line 23.
> (gdb) r
> Starting program: /mnt/afc_agent.exe
> warning: shared library handler failed to enable breakpoint

This is odd, but may have to do with libthread_db being linked static.

-COMMENT-------------------------------------------------------------
Yes, that library is statically linked

#ldd my_prog
         not a dynamic executable
-END COMMENT---------------------------------------------------------

I forget -- do we have linuxthreads debugging working with static link?
[question for the other maintainers]

-COMMENT---------------------------------------------------------------
I'm also interested very much in answer.
-END COMMENT-----------------------------------------------------------


> Reading symbols from shared object read from target memory...done.
> Loaded system supplied DSO at 0xffffe000

What's this?  System supplied DSO?

-COMMENT---------------------------------------------------------------
I suspect that gdb doesn't correctly guess that it works with static
executable.
-END COMMENT-----------------------------------------------------------

> Detaching after fork from child process 2322.
> Detaching after fork from child process 2325.

Ah... fork?  You know it is dangerous to mix threads and forks, don't
you?  If your process has spawned threads before it forks, you're 
almost guaranteed to be in bad trouble.

-COMMENT---------------------------------------------------------------
Yes, I know. The forks are really used for "exec".
-END COMMENT-----------------------------------------------------------

I didn't see any msgs from gdb saying a thread had been spawned, 
but the thread detection might be broken eg. by the fact that we
are linked statically.

Can you try dynamic linking, at least of the libthread_db library?

-COMMENT---------------------------------------------------------------
The dynamically linked application works fine with gdb. The problem occurs
with statically linked one.
-END COMMENT-----------------------------------------------------------

> 
> Program terminated with signal SIGKILL, Killed.
> The program no longer exists.
> Current language:  auto; currently c++
> 
> The next output string looks strange ' warning: shared library handler
> failed to enable breakpoint' as application is linked statically. Any
> advises?