[
https://issues.apache.org/jira/browse/LOGCXX-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17453817#comment-17453817
]
Tobias Frost edited comment on LOGCXX-431 at 12/7/21, 11:35 AM:
----------------------------------------------------------------
(I'm currently packaging liblog4cxx 0.12.1 for Debian, so I came across this
thread. I'm Not sure if this bug is actually still unsolved as JIRA thinks,, as
on github the PR #68 has been merged already.)
-Said that: Blocking Signals is probably the right thing to do. I'm not sure at
the moment (research to be done on my side), if _ALL_ signals should be
blocked; I not sure, for example whether SIGBUS, SIGFPE, SIGILL and SIGSEGV
should be blocked. (see sigprocmask(2) – blocking those can lead to undefined
behaviour if those signals arrive while blocked...) I'll try to do some
research and follow up then.- Made a small test programm, it should(tm) be
fine to block them.
It seems even that this blocking is ignored: My test program spawns a thread
while signals blocked and segfaults there by accessing a illegal memory
location . The signal is still delivered and the programm terminated as it
should. So it is fine and my worries unbased...
(Edit: did not complete the last sentence...)
was (Author: coldtobi):
(I'm currently packaging liblog4cxx 0.12.1 for Debian, so I came across this
thread. I'm Not sure if this bug is actually still unsolved as JIRA thinks,, as
on github the PR #68 has been merged already.)
-Said that: Blocking Signals is probably the right thing to do. I'm not sure at
the moment (research to be done on my side), if _ALL_ signals should be
blocked; I not sure, for example whether SIGBUS, SIGFPE, SIGILL and SIGSEGV
should be blocked. (see sigprocmask(2) – blocking those can lead to undefined
behaviour if those signals arrive while blocked...) I'll try to do some
research and follow up then.- Made a small test programm, it should(tm) be
fine to block them.
It seems even that this blocking is ignored: My test program spawns a thread
while signals blocked and segfaults there by accessing a illegal memory
location . The signal is still delivered and the programm terminated as it
should. So it is fine.
(Edit: did not complete the last sentence...)
> When log4cxx creates a thread, it doesn't block signals it's not using,
> leading to unreliable signal delivery for the calling process.
> --------------------------------------------------------------------------------------------------------------------------------------
>
> Key: LOGCXX-431
> URL: https://issues.apache.org/jira/browse/LOGCXX-431
> Project: Log4cxx
> Issue Type: Bug
> Affects Versions: 0.10.0
> Environment: Debian
> Reporter: Tobias Frost
> Priority: Major
>
> This bug was orginially reported in the Debian BTS,
> https://bugs.debian.org/548074
> As I could not find the bug here, I assume it has not been reported.
> Otherwise, please just let me know the reference :)
> Best regards,
> Tobias Frost
> Debian BTS Text:
> Package: liblog4cxx10
> Version: 0.10.0-1
> Severity: normal
> In a multithreaded program, POSIX signals are sent to an arbitrary
> thread that hasn't blocked them via sigprocmask(). This means that
> when it matters which thread gets the signal -- for instance, if
> sigwait() is being used to serialize signals -- the program must ensure
> that every other thread has blocked the signal in question. Otherwise,
> the signal might be delivered to the wrong thread and lost.
> liblog4cxx automatically starts threads sometimes, and it doesn't
> adjust their thread masks. It really should block out every signal
> that it isn't interested in itself, so that programs using sigwait()
> can also use log4cxx.
> See also #547212.
> Daniel
> -- System Information:
> Debian Release: squeeze/sid
> APT prefers unstable
> APT policy: (500, 'unstable'), (1, 'experimental')
> Architecture: i386 (i686)
> Kernel: Linux 2.6.30-1-686 (SMP w/2 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/bash
> Versions of packages liblog4cxx10 depends on:
> ii libapr1 1.3.8-1 The Apache Portable Runtime
> Librar
> ii libaprutil1 1.3.9+dfsg-1 The Apache Portable Runtime
> Utilit
> ii libc6 2.9-26 GNU C Library: Shared libraries
> ii libgcc1 1:4.4.1-3 GCC support library
> ii libstdc++6 4.4.1-3 The GNU Standard C++ Library v3
> ii libuuid1 2.16-3 Universally Unique ID library
> liblog4cxx10 recommends no packages.
> liblog4cxx10 suggests no packages.
> -- no debconf information
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
