On Tuesday 12 September 2006 04:02, Ryan Reading wrote: > The sane library and/or its backends don't seem to "clean up" after > themselves by > restoring signal handlers and/or signal masks. This isn't a problem for a > simple > application that only serves as a front end for libsane, but does cause > problems > in a modular application where libsane may not always be loaded. For > instance, > if I wrap libsane and access it indirectly through some component technology, > when the component that uses libsane is unloaded, the signal handlers > installed > by libsane and its backends will still be installed. Of course, the library > is no > longer loaded in the process memory space so the function pointers used for > the signal handlers are no longer valid. If a signal for that signal handler > is then received, it causes a SIGSEGV. > This can easily happen if you use a sane backend that sets a SIGCHLD signal > handler, unload the component consuming libsane, and then use system(3) > to launch a shell command. > Is this a problem or is there something I'm missing here? > Does anyone have any advice on the "correct" way to work around this problem? > > Thanks!-- Ryan
Hi Ryan, FOA, don't post HTML mails! And yes, I think you are right. Grep for sigaction or signal function calls within the backend directory and you'll see, that no backend saves the old sigmasks or handlers for restoring. Even sanei_thread does not restore the tweaked masks/handlers. Workaround could be to get the settings before calling any sane function and to do the restore stuff on your own. Which backend are you using? Gerhard
