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 mailing list: sane-devellists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/sane-d
evel
Unsubscribe: Send mail with subject "unsubscribe
your_password"
             to sane-devel-requestlists.alioth.debian.org

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 mailing list: sane-devellists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/sane-d
evel
Unsubscribe: Send mail with subject "unsubscribe
your_password"
             to sane-devel-requestlists.alioth.debian.org

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-devellists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/sane-d
evel
Unsubscribe: Send mail with subject "unsubscribe
your_password"
             to sane-devel-requestlists.alioth.debian.org

On 9/15/06, Gerhard Jaeger <gerhardgjaeger.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-devellists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/sane-d
evel
> Unsubscribe: Send mail with subject "unsubscribe
your_password"
>              to sane-devel-requestlists.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 mailing list: sane-devellists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/sane-d
evel
Unsubscribe: Send mail with subject "unsubscribe
your_password"
             to sane-devel-requestlists.alioth.debian.org

On 9/15/06, Gerhard Jaeger <gerhardgjaeger.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-devellists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/sane-d
evel
> Unsubscribe: Send mail with subject "unsubscribe
your_password"
>              to sane-devel-requestlists.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 mailing list: sane-devellists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/sane-d
evel
Unsubscribe: Send mail with subject "unsubscribe
your_password"
             to sane-devel-requestlists.alioth.debian.org

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 mailing list: sane-devellists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/sane-d
evel
Unsubscribe: Send mail with subject "unsubscribe
your_password"
             to sane-devel-requestlists.alioth.debian.org

On Friday 15 September 2006 16:12, Ryan Reading wrote:
> On 9/15/06, Gerhard Jaeger <gerhardgjaeger.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 mailing list: sane-devellists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/sane-d
evel
Unsubscribe: Send mail with subject "unsubscribe
your_password"
             to sane-devel-requestlists.alioth.debian.org

On Friday 15 September 2006 16:12, Ryan Reading wrote:
> On 9/15/06, Gerhard Jaeger <gerhardgjaeger.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 mailing list: sane-devellists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/sane-d
evel
Unsubscribe: Send mail with subject "unsubscribe
your_password"
             to sane-devel-requestlists.alioth.debian.org