Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Michael Snyder <Michael.Snyder@access-company.com>
To: Vadim Shmelev <vadim.shmelev@acronis.com>
Cc: 'Baurzhan Ismagulov' <ibr@radix50.net>, gdb@sourceware.org
Subject: RE: GDB receives SIGKILL
Date: Mon, 02 Apr 2007 17:54:00 -0000	[thread overview]
Message-ID: <1175536448.9195.10.camel@svmsnyderlnx.palmsource.com> (raw)
In-Reply-To: <200704021344.l32DiWiT016756@imap.acronis.ru>

On Mon, 2007-04-02 at 17:47 +0400, Vadim Shmelev wrote:
> Thanks for response, Baurzhan. I will try to describe the problem in

> 
> (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.

> 
> (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.
I forget -- do we have linuxthreads debugging working with static link?
[question for the other maintainers]

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

What's this?  System supplied DSO?

> 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.

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?

> 
> 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?


  reply	other threads:[~2007-04-02 17:54 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-02  7:54 Vadim Shmelev
2007-04-02 10:01 ` Baurzhan Ismagulov
2007-04-02 13:44   ` Vadim Shmelev
2007-04-02 17:54     ` Michael Snyder [this message]
2007-04-03  7:13       ` Vadim Shmelev
2007-04-03 14:37         ` Daniel Jacobowitz
2007-04-03 19:47         ` Michael Snyder
2007-04-04 12:47           ` Vadim Shmelev
2007-04-04 18:20             ` Michael Snyder

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1175536448.9195.10.camel@svmsnyderlnx.palmsource.com \
    --to=michael.snyder@access-company.com \
    --cc=gdb@sourceware.org \
    --cc=ibr@radix50.net \
    --cc=vadim.shmelev@acronis.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox