signal handling

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

signal handling

Usarin Heininga
I have a program that handles SIGFPE SIGILL SIGSEGV.
When such a signal is received it will run a crash dialog pop up, informing
the user about the crash.
The problem is that in the function  start_thread() in fuse_mt.c will block
all
signals including these ones, of course you can't block a SEGV signal, but the
handler associated with it will not run either.
Only if the main thread receives a SEGV signal the dialog will run, not when
the worker threads receive such a signal.
According to POSIX those signals shouldn't be blocked and if you do the
results are undefined, in this case the associated signal handler will not
run.
I don't see why the fuse library should block these kind of signals, because
that is up to the program using libfuse and not libfuse itself.
I vote for unblocking these signals and probably a few more i don't know of.

regards,
Usarin


-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP,
AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: signal handling

Joshua J. Berry
On Mon, Jul 11, 2005 at 11:55:52PM +0200, Usarin Heininga wrote:
> I don't see why the fuse library should block these kind of signals, because
> that is up to the program using libfuse and not libfuse itself.

I believe Miklos actively chose to block signals to worker threads to fix a
bug.

You may wish to read the ChangeLog.  Specifically, look for the entry about
signals on 2005-05-12.

--
Joshua J. Berry

"I haven't lost my mind -- it's backed up on tape somewhere."
    -- /usr/games/fortune

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: signal handling

Miklos Szeredi
In reply to this post by Usarin Heininga
> The problem is that in the function  start_thread() in fuse_mt.c will block
> all
> signals including these ones, of course you can't block a SEGV signal, but the
> handler associated with it will not run either.
> Only if the main thread receives a SEGV signal the dialog will run, not when
> the worker threads receive such a signal.
> According to POSIX those signals shouldn't be blocked and if you do the
> results are undefined, in this case the associated signal handler will not
> run.
> I don't see why the fuse library should block these kind of signals, because
> that is up to the program using libfuse and not libfuse itself.
> I vote for unblocking these signals and probably a few more i don't know of.

You are probably right.  Actually libfuse doesn't catch SEGV, etc.  It
only catches TERM, HUP and INT and ignores the PIPE signal.

I think blocking the signals in the child threads is a historic
remnant, from when the handler called exit().  Now it only sets a
flag, so it should be safe to let all threads receive all signals.

Does the following patch fix your problem?

Thanks,
Miklos

Index: lib/fuse_mt.c
===================================================================
RCS file: /cvsroot/fuse/fuse/lib/fuse_mt.c,v
retrieving revision 1.24
diff -u -r1.24 fuse_mt.c
--- lib/fuse_mt.c 21 Mar 2005 11:47:04 -0000 1.24
+++ lib/fuse_mt.c 12 Jul 2005 13:17:11 -0000
@@ -94,15 +94,7 @@
 
 static int start_thread(struct fuse_worker *w, pthread_t *thread_id)
 {
-    sigset_t oldset;
-    sigset_t newset;
-    int res;
-
-    /* Disallow signal reception in worker threads */
-    sigfillset(&newset);
-    pthread_sigmask(SIG_SETMASK, &newset, &oldset);
-    res = pthread_create(thread_id, NULL, do_work, w);
-    pthread_sigmask(SIG_SETMASK, &oldset, NULL);
+    int res = pthread_create(thread_id, NULL, do_work, w);
     if (res != 0) {
         fprintf(stderr, "fuse: error creating thread: %s\n", strerror(res));
         return -1;



-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP,
AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: signal handling

Miklos Szeredi
In reply to this post by Joshua J. Berry
> > I don't see why the fuse library should block these kind of
> > signals, because that is up to the program using libfuse and not
> > libfuse itself.
>
> I believe Miklos actively chose to block signals to worker threads
> to fix a bug.
>
> You may wish to read the ChangeLog.  Specifically, look for the
> entry about signals on 2005-05-12.

Yes.  But that is about signals sent to applications using the
filesystem.  I think Usarin was talking about signals sent to the
filesystem daemon itself.

Miklos


-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP,
AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel