From: Paul Marquess <Paul.Marquess@owmobility.com>
To: David Niklas <doark@mail.com>, "gdb@sourceware.org" <gdb@sourceware.org>
Subject: RE: collecting data from a coring process
Date: Mon, 05 Sep 2016 10:59:00 -0000 [thread overview]
Message-ID: <CY1PR0501MB117894AC4FE2AC6C3FA5BD0E95E60@CY1PR0501MB1178.namprd05.prod.outlook.com> (raw)
In-Reply-To: <20160831151611.1411e3f7@ulgy_thing>
From: David Niklas [mailto:doark@mail.com]
...
> > > 1) Why not dump the information that you are looking for into a file
> > > in the process signal handler ?
> >
> > Would love to, but I have no idea what state the process is in once
> > the SEGV has been triggered. Just taking pointes as an example, once
> > in the signal handler I'm in a situation where I can't trust that any
> > pointer contains a valid value. A quick search suggests I can guard
> > against that by using a signal handler. But I'm already in one! If
> > there is some prior art that shows how to safely dump data from a
> > process once a SEGV has been triggered it would make my day.
> > <snip>
>
> Oh, oh, I know how to do this (finally a chance to be of use on gdb's mailing list :) Ok, assuming that you know what variables you can access or that you can stick them in a struct what you do is enter the signal handler (hear after known as SH), printing the values one by one.
Can do that for a very limited sub-set of the data I'm dumping, but in general there is just too much data to remember that way.
> When one of the values causes a SEGV then you reenter SH which checks an atomic type to see if your in SH and if so then another atomic type to see if you've begun to print the values.
>
> If so then a new branch is executed and what gets printed is an inaccessible error value.
> Control returns to the first SH and it continues iterating.
Interesting technique for dealing with recursive signals.
Paul
P.S. Sorry for the delay in following up. Had no internet access for about 10 days.
prev parent reply other threads:[~2016-09-05 10:59 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-26 9:06 Paul Marquess
2016-08-26 12:01 ` vijay nag
2016-08-26 12:33 ` Paul Marquess
2016-08-28 7:48 ` Dmitry Samersoff
2016-09-05 11:10 ` Paul Marquess
2016-09-05 22:17 ` Samuel Bronson
2016-09-05 23:19 ` Paul Marquess
[not found] ` <CAJYzjmf0a2Dd8XbOQaO3937Bcab1AW9gVp=r3mKSgUq_27G8ow@mail.gmail.com>
2016-09-06 16:41 ` Paul Marquess
2016-09-07 19:22 ` Samuel Bronson
2016-09-07 22:10 ` Paul Marquess
[not found] ` <d327752e-89f6-c5a3-6d72-4789b106e1f6@samersoff.net>
2016-09-08 17:12 ` Paul Marquess
2016-09-01 4:23 ` David Niklas
2016-09-05 10:59 ` Paul Marquess [this message]
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=CY1PR0501MB117894AC4FE2AC6C3FA5BD0E95E60@CY1PR0501MB1178.namprd05.prod.outlook.com \
--to=paul.marquess@owmobility.com \
--cc=doark@mail.com \
--cc=gdb@sourceware.org \
/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