On Jan 10, 2010, at 6:44 AM, Marc Lehmann <[email protected]> wrote:
On Sat, Jan 09, 2010 at 10:03:03AM -0800, Tim McClarren <[email protected]
> wrote:
of ev_signal was to attempt to deliver asynchronous signals
synchronously.
Exactly - so what do you expect?
I'd expect libev to not catch it, I think... if the behavior of the
example code is as intended, let's leave it at that. I'm not sure
I'm
an idiot for thinking it might call back into the handler on SEGV.
If
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.
there was absolutely no reason for you to ever have a handler for
SEGV,
Well, no.
then I'm guessing that the POSIX spec. would treat it the same as
SIGKILL.
Well, no.
What you are trying is to magically recover from sigsegv.
As I said, I'm not. My handler attempts to get some stack frames, and
then re-raises.
I am trying to emit a stack to the log. I've done this before,
via the
usually sigaction route.
Again, you know you can't continue, so why bother?
Because I want the call stack?
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.
Anyways, changing back to using sigaction for getting the stack is
easy
enough.
Yes, and it makes sense for your case.
--
The choice of a Deliantra, the free code
+content MORPG
-----==- _GNU_ http://www.deliantra.net
----==-- _ generation
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / [email protected]
-=====/_/_//_/\_,_/ /_/\_\
_______________________________________________
libev mailing list
[email protected]
http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev