Marc Lehmann wrote:
On Sun, Jan 10, 2010 at 09:14:04AM -0800, Tim McClarren <[email protected]>
wrote:
Not sure who claimed you are an idiot, but you don't understand
SIGSEGV and
how it works.
I think I do, in fact. I use the same handler for the other "abort"
signals. FPE, BUS, etc.
Then I fail to understand your surprise. Honestly.
You can't get it that way - when you handler is called from the event
loop, you will have the call stack from the event loop.
Yes, I can't get it if I am called once the event loop is unrolled. My
misreading of the docs was that libev would not just deliver this event
immediately instead of attempting to unroll. That it should try that for
signals for which the handler cannot return was the part I found
unexpected.
There is no unrolling in any way going on. libev converts asynchronous
signals into synchronous signals. What you wish to do simply cannot be done,
and simply makes no sense.
What is your understanding of what I wish to do? I was pretty clear: I
want to get a few stack frames on SEGV. That's it. I don't think
that's a "fundamental misunderstanding", and if you think it is, then
you should probably also make sure the Google Breakpad folks know as
well, because they do precisely the same thing (and quite a lot more)
with SEGV.
The reason I keep mentioning that you don't seem to understand the
semantics of SEGV is that you keep saying that it should be done in a
way that absolutely makes no sense. (And yes, sure, you can return from
SIGSEGV handlers, it's just that libev can't do this automatically, I
explained this before).
Which way is that? I assumed that signals which could not be delivered
by setting some sig_atomic and then checking it in the libev loop (this
is turning async. signals into synchronous ones, is it not?) would be
*still be delivered*. Mea culpa. I should have followed the part about
just using sigaction. However, my experience with signal handlers
suggests that having only one piece of code installing them is, in
general, a good idea.
_______________________________________________
libev mailing list
[email protected]
http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
