I'm actually using DDD, and it's a multithreaded program.
This program("proSon") is started by another program, say "ProFather", and it has many siblings.
When the program breaks at my breakpoint 1, and I start checking the data structures, at some point, it seems the debugged process is terminated unexpectedly, and DDD prints: "Can't detach process... No Such Process"
I'm wondering, if gdb breaks, this process should be halted and nothing should be executed, how can this process be terminated and DDD doesn't know?
(I don't if it has to do with the signal handler, however, through "info signals", it shows that SIGKILL and SIGINT should be printed when process receives such signal, however, nothing has been printed!)
On Oct 13, 6:59 am, lander <lostlander....@gmail.com> wrote: [snip]
> (I don't if it has to do with the signal handler, however, through > "info signals", it shows that SIGKILL and SIGINT should be printed > when process receives such signal, however, nothing has been printed!)
You must have a defective "info" database, then, as SIGKILL and SIGINT do no such thing.
If not caught by the process and handled or ignored, SIGINT will *silently* terminate the target process.
If not caught by the process and handled or ignored, SIGKILL will also *silently* terminate the target process.
In neither case will the signal "be printed" when delivered to the process. The *only* way that could happen is if the process were to install an explicit signal handler for the signals, and explicitly print something when the signal handler were invoked.
On Tue, 13 Oct 2009 18:20:02 -0700 (PDT), Lew Pitcher
<lpitc...@teksavvy.com> wrote: > On Oct 13, 6:59 am, lander <lostlander....@gmail.com> wrote: >> (I don't if it has to do with the signal handler, however, through >> "info signals", it shows that SIGKILL and SIGINT should be printed >> when process receives such signal, however, nothing has been printed!)
> You must have a defective "info" database, then, as SIGKILL and SIGINT > do no such thing.
> If not caught by the process and handled or ignored, SIGINT will > *silently* terminate the target process.
But I think gdb installs handlers for INT and KILL (and many other signals). So if he's talking about "info signals" from _within_ gdb, then he may be right.
In the case of INT, IIRC gdb prints the signal name and stops the process being debugged as if it hit breakpoint rather than passing the signal on.
For other signals it does pass them on but also prints the signal name so you know that it happened.
There's some way to change this behavior that I can't remember right now.
> On Tue, 13 Oct 2009 18:20:02 -0700 (PDT), Lew Pitcher
> <lpitc...@teksavvy.com> wrote: > > On Oct 13, 6:59 am, lander <lostlander....@gmail.com> wrote: > >> (I don't if it has to do with the signal handler, however, through > >> "info signals", it shows that SIGKILL and SIGINT should be printed > >> when process receives such signal, however, nothing has been printed!)
> > You must have a defective "info" database, then, as SIGKILL and SIGINT > > do no such thing.
> > If not caught by the process and handled or ignored, SIGINT will > > *silently* terminate the target process.
> But I think gdb installs handlers for INT and KILL (and many other > signals). So if he's talking about "info signals" from _within_ gdb, > then he may be right.
> In the case of INT, IIRC gdb prints the signal name and stops the > process being debugged as if it hit breakpoint rather than passing the > signal on.
> For other signals it does pass them on but also prints the signal name > so you know that it happened.
> There's some way to change this behavior that I can't remember right > now.
The command to change the default behavior is "handle signal Action [stop/pass etc]"
However, no information is printed out when the process is terminated, when the process is stopped by gdb, how come the debugged process get terminated *silently*??
lander wrote: > On 10月15日, 上午6时12分, Bob Hauck <postmas...@avalanche.org> wrote: >> On Tue, 13 Oct 2009 18:20:02 -0700 (PDT), Lew Pitcher
>> <lpitc...@teksavvy.com> wrote: >>> On Oct 13, 6:59 am, lander <lostlander....@gmail.com> wrote: >>>> (I don't if it has to do with the signal handler, however, through >>>> "info signals", it shows that SIGKILL and SIGINT should be printed >>>> when process receives such signal, however, nothing has been printed!) >>> You must have a defective "info" database, then, as SIGKILL and SIGINT >>> do no such thing. >>> If not caught by the process and handled or ignored, SIGINT will >>> *silently* terminate the target process. >> But I think gdb installs handlers for INT and KILL (and many other >> signals). So if he's talking about "info signals" from _within_ gdb, >> then he may be right.
>> In the case of INT, IIRC gdb prints the signal name and stops the >> process being debugged as if it hit breakpoint rather than passing the >> signal on.
>> For other signals it does pass them on but also prints the signal name >> so you know that it happened.
>> There's some way to change this behavior that I can't remember right >> now.
> The command to change the default behavior is "handle signal Action > [stop/pass etc]"
> However, no information is printed out when the process is > terminated, > when the process is stopped by gdb, how come the debugged process get > terminated *silently*??
It would be a good idea to ask this question over on the gdb mailing list, g...@sourceware.org. One thing, though -- they are going to tell you "we don't know anything about ddd", so you might want to be ready to discuss how gdb behaves if ddd is taken out of the picture.
I can tell you this much -- gdb would tell you if your program received SIGINT, but SIGKILL cannot be handled. If one of the other processes in your process group (or anyone else, really) sends you SIGKILL, your process will just silently go away, much the way you describe it.
|
