* elfutls using assert
@ 2007-07-09 12:38 Andrew Cagney
2007-07-09 23:08 ` Roland McGrath
0 siblings, 1 reply; 5+ messages in thread
From: Andrew Cagney @ 2007-07-09 12:38 UTC (permalink / raw)
To: Roland McGrath; +Cc: frysk
Roland,
Mike and I noticed that elfutils uses assert() which, in turn, calls
abort(). Is there a way to override this, having the code instead call
a callback? That way, should an assertion fail, frysk will be able to
at least report the issue before exiting.
Andrew
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: elfutls using assert
2007-07-09 12:38 elfutls using assert Andrew Cagney
@ 2007-07-09 23:08 ` Roland McGrath
2007-07-10 15:34 ` Andrew Cagney
0 siblings, 1 reply; 5+ messages in thread
From: Roland McGrath @ 2007-07-09 23:08 UTC (permalink / raw)
To: Andrew Cagney; +Cc: frysk
No, there is no way not to call abort. It is used for situations that are
pathological in the same way as a clobbered pointer that might lead to a
crash. If you want to improve recovery from such bugs, you might as well
catch all unexpected fatal signals and diagnose gracefully there (maybe if
things aren't too bad you can throw an exception from the signal handler
and never consult the clobbered data structures while reporting and exiting).
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: elfutls using assert
2007-07-09 23:08 ` Roland McGrath
@ 2007-07-10 15:34 ` Andrew Cagney
2007-07-10 18:47 ` Roland McGrath
0 siblings, 1 reply; 5+ messages in thread
From: Andrew Cagney @ 2007-07-10 15:34 UTC (permalink / raw)
To: Roland McGrath; +Cc: frysk
Unless I'm mistaken, it isn't possible to attach the abort signal as it
may be sent to any thread? Anyway, to make the problem more concrete,
when a panic like this occurs, frysk needs time to pull all inserted
breakpoints before detaching from the program and exiting.
Andrew
Roland McGrath wrote:
> No, there is no way not to call abort. It is used for situations that are
> pathological in the same way as a clobbered pointer that might lead to a
> crash. If you want to improve recovery from such bugs, you might as well
> catch all unexpected fatal signals and diagnose gracefully there (maybe if
> things aren't too bad you can throw an exception from the signal handler
> and never consult the clobbered data structures while reporting and exiting).
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: elfutls using assert
2007-07-10 15:34 ` Andrew Cagney
@ 2007-07-10 18:47 ` Roland McGrath
2007-07-12 15:10 ` Andrew Cagney
0 siblings, 1 reply; 5+ messages in thread
From: Roland McGrath @ 2007-07-10 18:47 UTC (permalink / raw)
To: Andrew Cagney; +Cc: frysk
> Unless I'm mistaken, it isn't possible to attach the abort signal as it
> may be sent to any thread?
You are mistaken. If you are catching the signal, you will catch all such
signals in whatever thread they are delivered. Anyway, abort is equivalent
to raise (SIGABRT), which means synchronously to the calling thread (the
signal will appear to happen immediately after the syscall instruction for
the syscall that performs the "raise").
> Anyway, to make the problem more concrete, when a panic like this occurs,
> frysk needs time to pull all inserted breakpoints before detaching from
> the program and exiting.
Like I said, when one of these hits, you are lucky if all memory is not
randomly clobbered already. But if you just avoid anything that would call
into elfutils libs at all, you might be avoiding the memory that is
definitely clobbered already, and be lucky enough to survive long enough to
withdraw gracefully.
Thanks,
Roland
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: elfutls using assert
2007-07-10 18:47 ` Roland McGrath
@ 2007-07-12 15:10 ` Andrew Cagney
0 siblings, 0 replies; 5+ messages in thread
From: Andrew Cagney @ 2007-07-12 15:10 UTC (permalink / raw)
To: Roland McGrath; +Cc: frysk
Roland McGrath wrote:
>> Unless I'm mistaken, it isn't possible to attach the abort signal as it
>> may be sent to any thread?
>>
>
>
Good, I'll add code to attempt that.
> You are mistaken. If you are catching the signal, you will catch all such
> signals in whatever thread they are delivered. Anyway, abort is equivalent
> to raise (SIGABRT), which means synchronously to the calling thread (the
> signal will appear to happen immediately after the syscall instruction for
> the syscall that performs the "raise").
>
>
>> Anyway, to make the problem more concrete, when a panic like this occurs,
>> frysk needs time to pull all inserted breakpoints before detaching from
>> the program and exiting.
>>
>
> Like I said, when one of these hits, you are lucky if all memory is not
> randomly clobbered already. But if you just avoid anything that would call
> into elfutils libs at all, you might be avoiding the memory that is
> definitely clobbered already, and be lucky enough to survive long enough to
> withdraw gracefully.
>
>
> Thanks,
> Roland
>
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2007-07-12 15:10 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-07-09 12:38 elfutls using assert Andrew Cagney
2007-07-09 23:08 ` Roland McGrath
2007-07-10 15:34 ` Andrew Cagney
2007-07-10 18:47 ` Roland McGrath
2007-07-12 15:10 ` Andrew Cagney
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).