Dumping core and going on

Dumping core and going on

Post by Gildas Quinio » Tue, 21 Apr 1998 04:00:00



Hi!

Is there a way to dump a core on some catched signals and then keep the
process running?
I need to analyze some misbehavior on a program but I wouldn't want to
have it die since some problems are minor ones...

Thanks for any kind of help!

Gildas Quiniou.

--
/-----------------------------*-----------------------------\
| Systmes & Technologies     | Tl:     +33 2 96438787     |
| Informatiques du Ponant     | Fax:     +33 2 96438788     |
| 27, rue Auguste Brizeux     | web:     http://www.stip.fr |
| 22200 Guingamp - France     | Minitel: 3615 STIP          |
\-----------------------------*-----------------------------/

 
 
 

Dumping core and going on

Post by Simon Tath » Tue, 21 Apr 1998 04:00:00



Quote:> Is there a way to dump a core on some catched signals and then keep the
> process running?

Not that I know of, but you can attach a gdb to an already running
process: `gdb programname pid'. So you could run your program,
attach gdb to it, set a breakpoint in the signal handler for
whatever signal you're thinking of, and let it run.
--
Simon Tatham. Trinity College, Cambridge, CB2 1TQ, England.


No (good) Web page.    But if I keep talking, I can drive them insane."

 
 
 

Dumping core and going on

Post by Paul Flinder » Tue, 21 Apr 1998 04:00:00




> > Is there a way to dump a core on some catched signals and then keep the
> > process running?

> Not that I know of, but you can attach a gdb to an already running
> process: `gdb programname pid'. So you could run your program,
> attach gdb to it, set a breakpoint in the signal handler for
> whatever signal you're thinking of, and let it run.
> --

I assume that the concern of the original poster is to keep some sort
of server running even if it crashes.

What he could do, I suppose, is catch signals like SIGSEGV, SIGBUS,
SIGILL etc, fork then have the child continue processing and allow the
parent to dump core.

The real issue, however, is how you can arrange to avoid segfaulting
again in fairly short order - after all the fact that you ran of the
end of mapped memory or executed garbage usually implies some memory
corruption. You're not going to be able to guarentee that you can
continue to use malloc safely for instance.

You could do a heap consistency check - but if you do and the heap
isn't consistent what do you do? (answer left as an exercise for the
reader :-) )

--
Paul

 
 
 

Dumping core and going on

Post by Gildas Quinio » Tue, 21 Apr 1998 04:00:00



> The real issue, however, is how you can arrange to avoid segfaulting
> again in fairly short order - after all the fact that you ran of the

I don't need to be sure to have a trustable environment after the core dump
because in the catch signal function I exec() another process that will take
place of the faulty one. This is what I already do but I would like to analyze
the core (if I find a way to dump it) later to track the bug(s) on the dead
processes. If anybody have an idea I will be glad to test it! ;-))

Thanks,

Gildas Quiniou.

--
/-----------------------------*-----------------------------\
| Systmes & Technologies     | Tl:     +33 2 96438787     |
| Informatiques du Ponant     | Fax:     +33 2 96438788     |
| 27, rue Auguste Brizeux     | web:     http://www.stip.fr |
| 22200 Guingamp - France     | Minitel: 3615 STIP          |
\-----------------------------*-----------------------------/

 
 
 

Dumping core and going on

Post by Paul Flinder » Tue, 21 Apr 1998 04:00:00




> > The real issue, however, is how you can arrange to avoid segfaulting
> > again in fairly short order - after all the fact that you ran of the

> I don't need to be sure to have a trustable environment after the core dump
> because in the catch signal function I exec() another process that will take
> place of the faulty one. This is what I already do but I would like to analyze
> the core (if I find a way to dump it) later to track the bug(s) on the dead
> processes. If anybody have an idea I will be glad to test it! ;-))

Ok you're planning to do "the right thing" - here's how to do what you
want (assuming posix signal semantics)

Set up a handler for SIGILL, SIGSGEV etc

in the handler

  1) reset the handler to the default action
  2) fork
  3) in the parent, chdir to somewhere to leave the core file then
     re-send the signal to yourself with kill and exit the handler
  4) in the child exec a new copy

This should get you a core dump with the program counter pointing at
the point the original segv or whatever occurred - it doesn't really
matter if you swap what you do in the parent and child (i.e. the
parent could do the exec if you want).

Remember that setuid programs don't leave core files.

Quote:> /-----------------------------*-----------------------------\
> | Systmes & Technologies     | Tl:     +33 2 96438787     |
> | Informatiques du Ponant     | Fax:     +33 2 96438788     |
> | 27, rue Auguste Brizeux     | web:     http://www.stip.fr |
> | 22200 Guingamp - France     | Minitel: 3615 STIP          |
> \-----------------------------*-----------------------------/

Nice place Guingamp, as I recall, but I never could get the hang of the
pronunciation :-(
 
 
 

Dumping core and going on

Post by Bjorn Ree » Wed, 22 Apr 1998 04:00:00



> Set up a handler for SIGILL, SIGSGEV etc

> in the handler

>   1) reset the handler to the default action
>   2) fork
>   3) in the parent, chdir to somewhere to leave the core file then
>      re-send the signal to yourself with kill and exit the handler
>   4) in the child exec a new copy

Any attempts to do anything except a graceful termination (ie. save
important data, log the error,) is bound to go wrong. The above may
appear to work, but you will be continueing with bad data. SIGSEGV
and similar indicates something is seriously wrong with the process.

It is much better to let the process die, and attempt to restart it
somehow (inittab, crontab, shell loop.)

 
 
 

Dumping core and going on

Post by Paul Flinder » Wed, 22 Apr 1998 04:00:00




> > Set up a handler for SIGILL, SIGSGEV etc

> > in the handler

> >   1) reset the handler to the default action
> >   2) fork
> >   3) in the parent, chdir to somewhere to leave the core file then
> >      re-send the signal to yourself with kill and exit the handler
> >   4) in the child exec a new copy

> Any attempts to do anything except a graceful termination (ie. save
> important data, log the error,) is bound to go wrong. The above may
> appear to work, but you will be continueing with bad data. SIGSEGV
> and similar indicates something is seriously wrong with the process.

I said this two posts ago.

Quote:

> It is much better to let the process die, and attempt to restart it
> somehow (inittab, crontab, shell loop.)

What does 4) do?

--
Paul

 
 
 

Dumping core and going on

Post by Stephane Jeanjea » Thu, 23 Apr 1998 04:00:00


Hi,

On SunOs there is an utility to get core images of running processes named
'gcore'.
I don't know if such utility exists for Linux.
A quick look to this program show that his main task is a copy from the
/proc
filesystem (where the memory image of the running process is accessible) to
a file
in a core format.

Hope that help.
Stephane Jeanjean


> Hi!

> Is there a way to dump a core on some catched signals and then keep the
> process running?
> I need to analyze some misbehavior on a program but I wouldn't want to
> have it die since some problems are minor ones...

> Thanks for any kind of help!

> Gildas Quiniou.

> --
> /-----------------------------*-----------------------------\
> | Systmes & Technologies     | Tl:     +33 2 96438787     |
> | Informatiques du Ponant     | Fax:     +33 2 96438788     |
> | 27, rue Auguste Brizeux     | web:     http://www.stip.fr |
> | 22200 Guingamp - France     | Minitel: 3615 STIP          |
> \-----------------------------*-----------------------------/

 
 
 

1. dump core or not dump core

Howdy,

Some of my programs dump core, others don't. I tried
it on RedHat 6.1 and Mandrake 7.0 with kernels 2.2.14
and 2.2.15. I tried tcsh and bash with coredumpsize
set to 1GB. It seems to be application specific.

Is there any other criteria when suppressing apart from
the type of signal and the size limitation?
The application that doesn't dump core contains signal
handlers for some signals, but not for SEGV or ABRT.

Ruppert

 -----------------------------------------------------------------

 Dept of Elec. & Comp. Engr.    http://alpha.ece.ucsb.edu/~ruppert
 University of California       Phone: (805) 893-7788
 Santa Barbara, CA 93106        Fax:   (805) 893-3262
 -----------------------------------------------------------------

2. Unknown Host message when accessing domains

3. core dumps core dumps everywhere...

4. Connect to demon and Linux Debian

5. Get "Segmentation fault (core dumped)" but no core file found

6. Mandrake 8.0

7. Apache problem - core dumps (httpd.core) all over the place

8. RH 4.1 i386: How can I make passwd unsecure?

9. XF86_SVGA core dumped, but where is the core file?

10. why are core dumps always named "core"?

11. GDB dumps core when given core?

12. want to dump core, then run the core later.

13. Going, going, going, GONE! Bye Windows!