[sane-devel] signal handling by libsane and backends
On Friday 15 September 2006 16:12, Ryan Reading wrote: On 9/15/06, Gerhard Jaeger gerh...@gjaeger.de wrote: On Thursday 14 September 2006 13:30, Wittawat Yamwong wrote: Hi, On Thursday 14 September 2006 09:09, Gerhard Jaeger wrote: 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. [...] 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. I think, it is OK if the backend modifies sigmasks and/or installs signal handlers in the _child_ process but doesn't restore them. On the other hand, as Ryan mentioned, it will probably cause problems if you do it in the parent process and do not take special care of old sigmasks and signal handlers. 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. This should be documented somewhere, maybe in PROBLEMS? Nope, I think it should be fixed... I digged a little deeper to sanei_thread and the only points, where we fiddle with signals is SIGPIPE and SIGUSR2 (only for __APPLE__ __MACH__) SIGPIPE will be restored SIGUSR2 not, which is IMHO not critical So the point to fix are inside the backends. If someone could provide a testcase, this could be easily fixed. Gerhard Thanks for the quick replies. (My bad on the HTML... I have no idea why I was even using hotmail). I agree that the handlers in the child process are not a big deal. The particular backend that I was using was plustek. It specifically sets a SIGCHLD handler. I think SIGALRM is affected in other backends. Anyway, I could put together a test case that exhibits the problem if needed. In what form should a test case be in to most useful? Where could I look for an example? I didn't see any code in the testsuite dir in the source tree. The plustek backend, that's what I expected ;) I'm the maintainer of this piece of code, so when returning from holiday, I'll try to fix that issue. Gerhard
[sane-devel] signal handling by libsane and backends
On Thursday 14 September 2006 13:30, Wittawat Yamwong wrote: Hi, On Thursday 14 September 2006 09:09, Gerhard Jaeger wrote: 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. [...] 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. I think, it is OK if the backend modifies sigmasks and/or installs signal handlers in the _child_ process but doesn't restore them. On the other hand, as Ryan mentioned, it will probably cause problems if you do it in the parent process and do not take special care of old sigmasks and signal handlers. 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. This should be documented somewhere, maybe in PROBLEMS? Nope, I think it should be fixed... I digged a little deeper to sanei_thread and the only points, where we fiddle with signals is SIGPIPE and SIGUSR2 (only for __APPLE__ __MACH__) SIGPIPE will be restored SIGUSR2 not, which is IMHO not critical So the point to fix are inside the backends. If someone could provide a testcase, this could be easily fixed. Gerhard
[sane-devel] signal handling by libsane and backends
On 9/15/06, Gerhard Jaeger gerh...@gjaeger.de wrote: On Thursday 14 September 2006 13:30, Wittawat Yamwong wrote: Hi, On Thursday 14 September 2006 09:09, Gerhard Jaeger wrote: 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. [...] 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. I think, it is OK if the backend modifies sigmasks and/or installs signal handlers in the _child_ process but doesn't restore them. On the other hand, as Ryan mentioned, it will probably cause problems if you do it in the parent process and do not take special care of old sigmasks and signal handlers. 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. This should be documented somewhere, maybe in PROBLEMS? Nope, I think it should be fixed... I digged a little deeper to sanei_thread and the only points, where we fiddle with signals is SIGPIPE and SIGUSR2 (only for __APPLE__ __MACH__) SIGPIPE will be restored SIGUSR2 not, which is IMHO not critical So the point to fix are inside the backends. If someone could provide a testcase, this could be easily fixed. Gerhard -- sane-devel mailing list: sane-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/sane-devel Unsubscribe: Send mail with subject unsubscribe your_password to sane-devel-requ...@lists.alioth.debian.org Thanks for the quick replies. (My bad on the HTML... I have no idea why I was even using hotmail). I agree that the handlers in the child process are not a big deal. The particular backend that I was using was plustek. It specifically sets a SIGCHLD handler. I think SIGALRM is affected in other backends. Anyway, I could put together a test case that exhibits the problem if needed. In what form should a test case be in to most useful? Where could I look for an example? I didn't see any code in the testsuite dir in the source tree. Anyway, I'm happy to do whatever needs to be done if someone can give me a nudge in the right direction. Thanks again. -- Ryan
[sane-devel] signal handling by libsane and backends
On Friday 15 September 2006 08:39, Gerhard Jaeger wrote:
[...]
So the point to fix are inside the backends. If someone could
provide a testcase, this could be easily fixed.
An example for SIGCHLD (as mentioned by Ryan):
- Main program
int main(int argc, char **argv)
{
void *so;
void (*foo)();
so = dlopen(./test1.so, RTLD_LAZY);
foo = dlsym(so, foo);
foo();
/* I don't need the library anymore. So I unload it. */
dlclose(so);
system(echo hello);
/* SIGSEGV here. */
return 0;
}
- test1.so -
static void sighandler(int sig)
{
}
void foo(void)
{
struct sigaction sa;
memset(sa, 0, sizeof(sa));
sigemptyset(sa.sa_mask);
sa.sa_handler = sighandler;
sigaction(SIGCHLD, sa, NULL);
/* forget to restore SIGCHLD handler. */
}
grep -l SIGCHLD *.c in the backend directory gives:
artec_eplus48u.c
mustek.c
plustek.c
plustek_pp.c
u12.c
Regards
--
Wittawat Yamwong
Hannover, Germany
[sane-devel] signal handling by libsane and backends
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
[sane-devel] signal handling by libsane and backends
Hi, On Thursday 14 September 2006 09:09, Gerhard Jaeger wrote: 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. [...] 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. I think, it is OK if the backend modifies sigmasks and/or installs signal handlers in the _child_ process but doesn't restore them. On the other hand, as Ryan mentioned, it will probably cause problems if you do it in the parent process and do not take special care of old sigmasks and signal handlers. 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. This should be documented somewhere, maybe in PROBLEMS? Regards -- Wittawat Yamwong Hannover, Germany
[sane-devel] signal handling by libsane and backends
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 _ Use Messenger to talk to your IM friends, even those on Yahoo! http://ideas.live.com/programpage.aspx?versionId=7adb59de-a857-45ba-81cc-685ee3e858fe -- next part -- An HTML attachment was scrubbed... URL: http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20060911/5bfc879d/attachment.html From r...@keenan.dk Tue Sep 12 12:26:40 2006 From: r...@keenan.dk (=?iso-8859-1?Q?Ren=E9_Kjellerup?=) Date: Tue Sep 12 18:52:13 2006 Subject: [sane-devel] Requesting progress on CanoScan 4200F Message-ID: 000d01c6d666$b3459d50$9d701005@rkj Hi' I know that as of yet the CanoScan 4200F is Unsupported by SANE http://www.sane-project.org/unsupported/canon-4200f.html All I wish to know is, is there somebody working On writing a backend, or is there plans for it to be included in the plustek or genesys backend? If not, then I could use some guidence on howto use libusb and the SANE API to write a backend, if anyone would be so kind. High hopes from Ren? Kjellerup
