Bug#572920: #572920: mpg123 broken after libltdl3 upgrade
I just verified, that removing cve-2009-3736.patch from series file and rebuilding libltdl3 package fixes mpg123. That patch stops libltdl from looking in CWD for .la files and that breaks mpg123 module loading. In case of mpg123 it does: chdir(/usr/lib/mpg123); lt_dlopen(type_module.la); BTW, when passing '-o /../X' mpg123 will happily lt_dlopen(type_/../X.la), but that's another story. Best Regards, Michał Mirosław -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#759324: [libdbd-oracle-perl] conflicts with perl-5.20
Package: libdbd-oracle-perl Version: 1.66 Severity: serious --- Please enter the report below this line. --- Please rebuild DBD::Oracle package with perl 5.20 from sid. Right now it can't be installed, because it depends on perlapi-5.18.1. Please consider using latest version. --- System information. --- Architecture: amd64 Kernel: Linux 3.16.1mq Debian Release: jessie/sid 900 testing www.deb-multimedia.org 900 testing security.debian.org 900 testing ftp.pl.debian.org 800 stable security.debian.org 800 stable ftp.pl.debian.org 700 unstablewww.deb-multimedia.org 700 unstableftp.pl.debian.org 600 experimentalftp.pl.debian.org 500 stable deb.opera.com 500 proposed-updates ftp.pl.debian.org 500 debian packages.linuxmint.com --- Package information. --- Depends(Version) | Installed -+-== libaio1 | libdbi-perl | oracle-instantclient12.1-basic | OR oracle-instantclient12.1-basiclite | perl (= 5.18.1-2) | perl-dbdabi-94 | perlapi-5.18.1 | libc6 (= 2.14) | Package's Recommends field is empty. Suggests (Version) | Installed ===-+-=== perl-tk | -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#749500: rakudo: not installable in sid
rakudo =2014.07-1 depends on nqp =2014.07-1, but only nqp =2014.07-2 is available. root@qmqm:~# apt-cache policy rakudo rakudo: Zainstalowana: 2014.03.01-1+b1 Kandydująca: 2014.07-1 Tabela wersji: 2014.07-1 0 700 http://ftp.pl.debian.org/debian/ sid/main amd64 Packages *** 2014.03.01-1+b1 0 100 /var/lib/dpkg/status 0.1~2012.01-1 0 800 http://ftp.pl.debian.org/debian/ wheezy/main amd64 Packages root@qmqm:~# apt-cache policy nqp nqp: Zainstalowana: 2014.04-3 Kandydująca: 2014.04-3 Tabela wersji: 2014.07-2 0 700 http://ftp.pl.debian.org/debian/ sid/main amd64 Packages *** 2014.04-3 0 900 http://ftp.pl.debian.org/debian/ jessie/main amd64 Packages 100 /var/lib/dpkg/status 0.1~2012.01-5 0 800 http://ftp.pl.debian.org/debian/ wheezy/main amd64 Packages -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#867988: nasm - fixed upstream
These seem to be fixed in upstream: https://bugzilla.nasm.us/show_bug.cgi?id=3392414 https://bugzilla.nasm.us/show_bug.cgi?id=3392415 Best Regards, Michał Mirosław
Bug#966692: stunnel4: FTBFS because of test hang
Source: stunnel4
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: Michał Mirosław
The bug #955710 turns out to be only partially fixed. Now without a binary
to exec the test runtime doesn't hang. When the binary is correct, though,
it still can't stop asking the pipe for more data after EOF.
$ dpkg-buildpackage -b
[...]
env TEST_STUNNEL=.../stunnel4-5.56+dfsg/src/stunnel debian/tests/runtime
Found the certificate at debian/tests/certs/certificate.pem and the private key
at debian/tests/certs/key.pem
Using the /tmp/AgCSdk8YKw temporary directory
About to get the stunnel version information
Got stunnel version 5.56
^Cmake[1]: *** [debian/rules:32: execute_before_dh_auto_test] Interrupt
make: *** [debian/rules:106: binary] Error 1
From the manual run under strace:
$ TEST_STUNNEL=src/stunnel strace -f -o /tmp/log debian/tests/runtime
I can see (excerpt):
11715 read(5,
11715 <... read resumed> "stunnel 5.56 on x86_64-pc-linux-"..., 8192) = 95
[more reads]
11715 read(5, "TIMEOUTbusy= 300 sec"..., 8192) = 178
11715 epoll_wait(3,
11715 <... epoll_wait resumed> [{EPOLLHUP, {u32=5, u64=4294967301}}], 64,
59743) = 1
11715 epoll_ctl(3, EPOLL_CTL_MOD, 5, {EPOLLIN, {u32=5, u64=4294967301}}
[11716 +++ exited with 0 +++]
11715 <... epoll_ctl resumed> ) = 0
11715 --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=11716,
si_uid=1000, si_status=0, si_utime=0, si_stime=0} ---
11715 write(4, "\1\0\0\0\0\0\0\0", 8) = 8
11715 rt_sigreturn({mask=[]}) = 0
11715 epoll_wait(3, [{EPOLLHUP, {u32=5, u64=4294967301}}, {EPOLLIN, {u32=4,
u64=4294967300}}], 64, 59743) = 2
11715 epoll_ctl(3, EPOLL_CTL_MOD, 5, {EPOLLIN, {u32=5, u64=4294967301}}) = 0
11715 read(4, "\1\0\0\0\0\0\0\0", 8)= 8
11715 wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}],
WNOHANG|WSTOPPED|WCONTINUED, NULL) = 11716
11715 wait4(-1, 0x7ffc665c7904, WNOHANG|WSTOPPED|WCONTINUED, NULL) = -1 ECHILD
(No child processes)
11715 wait4(-1, 0x7ffc665c76b4, WNOHANG, NULL) = -1 ECHILD (No child processes)
11715 epoll_wait(3, [{EPOLLHUP, {u32=5, u64=4294967301}}], 64, 59743) = 1
11715 epoll_ctl(3, EPOLL_CTL_MOD, 5, {EPOLLIN, {u32=5, u64=4294967301}}) = 0
11715 epoll_wait(3, [{EPOLLHUP, {u32=5, u64=4294967301}}], 64, 59743) = 1
11715 epoll_ctl(3, EPOLL_CTL_MOD, 5, {EPOLLIN, {u32=5, u64=4294967301}}) = 0
11715 epoll_wait(3, [{EPOLLHUP, {u32=5, u64=4294967301}}], 64, 59743) = 1
11715 epoll_ctl(3, EPOLL_CTL_MOD, 5, {EPOLLIN, {u32=5, u64=4294967301}}) = 0
11715 read(5, "", 8192) = 0
11715 write(1, "Got stunnel version 5.56\n", 25) = 25
11715 epoll_wait(3, [{EPOLLHUP, {u32=5, u64=4294967301}}], 64, 59743) = 1
11715 epoll_ctl(3, EPOLL_CTL_MOD, 5, {EPOLLIN, {u32=5, u64=4294967301}}) = 0
11715 read(5, "", 8192) = 0
[last 3 lines repeated forever]
-- System Information:
Debian Release: 10.5
APT prefers stable-debug
APT policy: (900, 'stable-debug'), (900, 'proposed-updates'), (900,
'stable'), (800, 'testing'), (700, 'unstable'), (600, 'experimental'), (540,
'oldstable'), (500, 'unstable-debug'), (500, 'testing-debug'), (500,
'proposed-updates-debug'), (1, 'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.7.10mq+ (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
-- no debconf information
test-runtime.strace.log.gz
Description: application/gzip
Bug#966692: stunnel4: FTBFS because of test hang
On Sun, Aug 02, 2020 at 05:34:40PM +0300, Peter Pentchev wrote:
> On Sun, Aug 02, 2020 at 02:02:22AM +0200, Michał Mirosław wrote:
[...]
> --- a/debian/tests/runtime
> +++ b/debian/tests/runtime
> @@ -432,6 +432,7 @@ MAIN:
>
> if (!defined $line) {
> $eof->send($got_version);
> + undef $f_out;
> } elsif (!$got_version) {
> if ($line =~ m{^
> stunnel \s+
I believe $f_out will not be defined here, as it only gets set after
sub{} is created. Perl confirms this:
$ TEST_STUNNEL=src/stunnel strace -f -o /tmp/log debian/tests/runtime
Global symbol "$f_out" requires explicit package name (did you forget to
declare "my $f_out"?) at debian/tests/runtime line 435.
Execution of debian/tests/runtime aborted due to compilation errors.
$ dpkg -l perl
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-==---=
ii perl 5.28.1-6 amd64Larry Wall's Practical Extraction
and Report Language
Best Regards
Michał Mirosław
Bug#966692: stunnel4: FTBFS because of test hang
On Wed, Aug 05, 2020 at 09:28:12PM +0300, Peter Pentchev wrote:
> On Wed, Aug 05, 2020 at 08:01:53PM +0200, Michał Mirosław wrote:
> > On Sun, Aug 02, 2020 at 05:34:40PM +0300, Peter Pentchev wrote:
> > > On Sun, Aug 02, 2020 at 02:02:22AM +0200, Michał Mirosław wrote:
> > [...]
> > > --- a/debian/tests/runtime
> > > +++ b/debian/tests/runtime
> > > @@ -432,6 +432,7 @@ MAIN:
> > >
> > > if (!defined $line) {
> > > $eof->send($got_version);
> > > + undef $f_out;
> > > } elsif (!$got_version) {
> > > if ($line =~ m{^
> > > stunnel \s+
> >
> > I believe $f_out will not be defined here, as it only gets set after
> > sub{} is created. Perl confirms this:
> >
> > $ TEST_STUNNEL=src/stunnel strace -f -o /tmp/log debian/tests/runtime
> > Global symbol "$f_out" requires explicit package name (did you forget to
> > declare "my $f_out"?) at debian/tests/runtime line 435.
> > Execution of debian/tests/runtime aborted due to compilation errors.
>
> Of course you're right. Sorry about that! That's what I get for writing
> a patch three minutes before I have to head out and never remembering to
> actually test it later :(
>
> How about the attached one?
[...]
> --- a/debian/tests/runtime
> +++ b/debian/tests/runtime
> @@ -424,7 +424,8 @@ MAIN:
>
> my ($got_version, $before_version) = (undef, '');
> my $eof = AnyEvent->condvar;
> - my $f_out = AnyEvent->io(
> + my $f_out;
> + $f_out = AnyEvent->io(
> fh => $s_in,
> poll => 'r',
> cb => sub {
> @@ -432,6 +433,7 @@ MAIN:
>
> if (!defined $line) {
> $eof->send($got_version);
> + undef $f_out;
> } elsif (!$got_version) {
> if ($line =~ m{^
> stunnel \s+
This stops the endless readings of EOF, but:
1. the FD gets leaked (shouldn't matter much, though)
2. the test hangs anyway
Using print-debugging, I see that it stops at wait_for_child line just
after printing the version. It seems that something is reaping the child
before the main thread has a chance to wait for it.
>From strace:
4285 +++ exited with 0 +++
4284 <... epoll_ctl resumed> ) = 0
4284 --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=4285,
si_uid=1000, si_status=0, si_utime=0, si_stime=0} ---
4284 write(4, "\1\0\0\0\0\0\0\0", 8) = 8
4284 rt_sigreturn({mask=[PIPE]}) = 0
4284 epoll_wait(3, [{EPOLLHUP, {u32=5, u64=4294967301}}, {EPOLLIN, {u32=4,
u64=4294967300}}], 64, 59743) = 2
4284 epoll_ctl(3, EPOLL_CTL_MOD, 5, {EPOLLIN, {u32=5, u64=4294967301}}) = 0
4284 read(4, "\1\0\0\0\0\0\0\0", 8)= 8
4284 wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}],
WNOHANG|WSTOPPED|WCONTINUED, NULL) = 4285
4284 wait4(-1, 0x7ffcd56d5784, WNOHANG|WSTOPPED|WCONTINUED, NULL) = -1 ECHILD
(No child processes)
4284 wait4(-1, 0x7ffcd56d5534, WNOHANG, NULL) = -1 ECHILD (No child processes)
This is before the 'wait_for_child' a few lines later.
4284 epoll_wait(3, [{EPOLLHUP, {u32=5, u64=4294967301}}], 64, 59743) = 1
4284 epoll_ctl(3, EPOLL_CTL_MOD, 5, {EPOLLIN, {u32=5, u64=4294967301}}) = 0
4284 read(5, "", 8192) = 0
4284 write(1, "Got stunnel version 5.56\n", 25) = 25
4284 write(2, "wait child 4285\n", 16) = 16
This is version printout plus my check.
4284 epoll_wait(3, [{EPOLLHUP, {u32=5, u64=4294967301}}], 64, 59743) = 1
4284 epoll_ctl(3, EPOLL_CTL_DEL, 5, 0x5631c0d44a40) = 0
This clears watcher for the pipe.
4284 epoll_wait(3, 0x5631c0d44a40, 64, 59743) = -1 EINTR (Interrupted system
call)
And this waits forever.
Best Regards
Michał Mirosław
Bug#966692: stunnel4: FTBFS because of test hang
On Thu, Aug 06, 2020 at 12:29:36AM +0300, Peter Pentchev wrote:
> On Wed, Aug 05, 2020 at 10:52:31PM +0200, Michał Mirosław wrote:
[...]
> > Using print-debugging, I see that it stops at wait_for_child line just
> > after printing the version. It seems that something is reaping the child
> > before the main thread has a chance to wait for it.
>
> OK, so the only thing that comes to my mind now is that you may be
> hitting a crazy, crazy race between register_child() and child_reaper(),
> and I say "a crazy, crazy race", because the test has to (apparently
> reproducibly) receive the CHLD signal exactly between the check and
> the creation in register_child()'s first "$children{...} //= ...cv"
> statement.
Well, there is nothing that prevents SIGCHLD arriving between fork() and
register_child(). You could test this with more confidence (though not
100%-reliably) by putting 'exit 1' just at the start of ($pid == 0) branch.
> Can you apply the following patch and show me the output of running
> the test?
Sure, but I got no patch. :-)
Best Regards,
Michał Mirosław
Bug#966692: stunnel4: FTBFS because of test hang
On Thu, Aug 06, 2020 at 03:16:35AM +0300, Peter Pentchev wrote:
> On Thu, Aug 06, 2020 at 12:48:10AM +0200, Michał Mirosław wrote:
> > On Thu, Aug 06, 2020 at 12:29:36AM +0300, Peter Pentchev wrote:
> > > On Wed, Aug 05, 2020 at 10:52:31PM +0200, Michał Mirosław wrote:
> > [...]
> > > > Using print-debugging, I see that it stops at wait_for_child line just
> > > > after printing the version. It seems that something is reaping the child
> > > > before the main thread has a chance to wait for it.
> > >
> > > OK, so the only thing that comes to my mind now is that you may be
> > > hitting a crazy, crazy race between register_child() and child_reaper(),
> > > and I say "a crazy, crazy race", because the test has to (apparently
> > > reproducibly) receive the CHLD signal exactly between the check and
> > > the creation in register_child()'s first "$children{...} //= ...cv"
> > > statement.
> >
> > Well, there is nothing that prevents SIGCHLD arriving between fork() and
> > register_child(). You could test this with more confidence (though not
> > 100%-reliably) by putting 'exit 1' just at the start of ($pid == 0) branch.
>
> Nah, the problem is not just "between fork() and register_child()".
> It really must arrive at a very specific moment in time, because
> the //= operations for setting $children{$pid}{cv} try to make sure that
> a new value is not set (that is, a new condition variable is not
> created) if there already is such an element in the array. So the race
> is indeed between the //= in register_child() and the //= in
> child_reaper() - that is, child_reaper() must be invoked (SIGCHLD must
> arrive) *during* the execution of the //= in register_child().
>
> Unless I'm missing something, which is not at all out of the question :)
The assignment seems not to be at fault (see last strace). I don't know perl's
internals enough to say if this statement can be interrupted visibly by a signal
handler (I would guess not a perl handler, though). There are two wait4() calls
even before child_reaper has a chance to run.
> > > Can you apply the following patch and show me the output of running
> > > the test?
> >
> > Sure, but I got no patch. :-)
>
> Oof. Not my day, is it... Here it is... I hope.
[cut patch]
With the patch applied:
$ TEST_STUNNEL=src/stunnel strace -f -o /tmp/log debian/tests/runtime
Found the certificate at debian/tests/certs/certificate.pem and the
private key at debian/tests/certs/key.pem
Using the /tmp/user/1000/EklzlCzeRO temporary directory
About to get the stunnel version information
register_child: pid 14943 cv AnyEvent::CondVar=HASH(0x559e0d7572e0)
RDBG child_reaper() invoked
RDBG - pid -1 status -1
RDBG - done
RDBG - out of the child_reaper() loop
Got stunnel version 5.56
^C
And in the strace log:
14942 epoll_wait(3, [{EPOLLIN, {u32=5, u64=4294967301}}], 64, 59743) = 1
14942 epoll_wait(3, [{EPOLLIN, {u32=5, u64=4294967301}}], 64, 59743) = 1
14943 exit_group(0
14942 read(5,
14943 <... exit_group resumed>) = ?
14942 <... read resumed> "TIMEOUTconnect = 10 seco"..., 8192) = 105
14942 epoll_wait(3, [{EPOLLHUP, {u32=5, u64=4294967301}}], 64, 59743) = 1
14943 +++ exited with 0 +++
14942 epoll_ctl(3, EPOLL_CTL_MOD, 5, {EPOLLIN, {u32=5, u64=4294967301}}) = 0
14942 --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=14943,
si_uid=1000, si_status=0, si_utime=0, si_stime=0} ---
14942 write(4, "\1\0\0\0\0\0\0\0", 8) = 8
14942 rt_sigreturn({mask=[PIPE]}) = 0
14942 epoll_wait(3, [{EPOLLHUP, {u32=5, u64=4294967301}}, {EPOLLIN, {u32=4,
u64=4294967300}}], 64, 59743) = 2
14942 epoll_ctl(3, EPOLL_CTL_MOD, 5, {EPOLLIN, {u32=5, u64=4294967301}}) = 0
14942 read(4, "\1\0\0\0\0\0\0\0", 8)= 8
14942 wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}],
WNOHANG|WSTOPPED|WCONTINUED, NULL) = 14943
14942 wait4(-1, 0x7fffcacfddc4, WNOHANG|WSTOPPED|WCONTINUED, NULL) = -1 ECHILD
(No child processes)
14942 write(1, "RDBG child_reaper() invoked\n", 28) = 28
14942 wait4(-1, 0x7fffcacfdb74, WNOHANG, NULL) = -1 ECHILD (No child processes)
14942 write(1, "RDBG - pid -1 status -1\n", 24) = 24
14942 write(1, "RDBG - done\n", 14) = 14
14942 write(1, "RDBG - out of the child_reaper()"..., 38) = 38
14942 epoll_wait(3, [{EPOLLHUP, {u32=5, u64=4294967301}}], 64, 59743) = 1
14942 epoll_ctl(3, EPOLL_CTL_MOD, 5, {EPOLLIN, {u32=5, u64=4294967301}}) = 0
14942 read(5, "", 8192) = 0
14942 write(1, "Got stunnel version 5.56\n", 25) = 25
14942 epoll_wait(3, [{EPOLLHUP, {u32=5, u64=4294967301}}], 64, 59743) = 1
14942 epoll_ctl(3, EPOLL_CTL_DEL, 5, 0x559e0dba9760) = 0
14942 epoll_wait(3, 0x559e0dba9760, 64, 59743)
Bug#966692: stunnel4: FTBFS because of test hang
On Thu, Aug 06, 2020 at 02:39:42AM +0200, Michał Mirosław wrote:
> On Thu, Aug 06, 2020 at 03:16:35AM +0300, Peter Pentchev wrote:
> > On Thu, Aug 06, 2020 at 12:48:10AM +0200, Michał Mirosław wrote:
> > > On Thu, Aug 06, 2020 at 12:29:36AM +0300, Peter Pentchev wrote:
> > > > On Wed, Aug 05, 2020 at 10:52:31PM +0200, Michał Mirosław wrote:
> > > [...]
> > > > > Using print-debugging, I see that it stops at wait_for_child line just
> > > > > after printing the version. It seems that something is reaping the
> > > > > child
> > > > > before the main thread has a chance to wait for it.
> > > >
> > > > OK, so the only thing that comes to my mind now is that you may be
> > > > hitting a crazy, crazy race between register_child() and child_reaper(),
> > > > and I say "a crazy, crazy race", because the test has to (apparently
> > > > reproducibly) receive the CHLD signal exactly between the check and
> > > > the creation in register_child()'s first "$children{...} //= ...cv"
> > > > statement.
> > >
> > > Well, there is nothing that prevents SIGCHLD arriving between fork() and
> > > register_child(). You could test this with more confidence (though not
> > > 100%-reliably) by putting 'exit 1' just at the start of ($pid == 0)
> > > branch.
> >
> > Nah, the problem is not just "between fork() and register_child()".
> > It really must arrive at a very specific moment in time, because
> > the //= operations for setting $children{$pid}{cv} try to make sure that
> > a new value is not set (that is, a new condition variable is not
> > created) if there already is such an element in the array. So the race
> > is indeed between the //= in register_child() and the //= in
> > child_reaper() - that is, child_reaper() must be invoked (SIGCHLD must
> > arrive) *during* the execution of the //= in register_child().
> >
> > Unless I'm missing something, which is not at all out of the question :)
>
> The assignment seems not to be at fault (see last strace). I don't know perl's
> internals enough to say if this statement can be interrupted visibly by a
> signal
> handler (I would guess not a perl handler, though). There are two wait4()
> calls
> even before child_reaper has a chance to run.
Another data point: this happens only with anyevent + libev and not with
anyevent + libevent. The first is preferred and installed by default with
libanyevent-perl, though.
$ dpkg -l libanyevent-perl libev-perl | cat
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++----
ii libanyevent-perl 7.140-3 amd64event loop framework with
multiple implementations
ii libev-perl 4.25-1 amd64Perl interface to libev, the
high performance event loop
Best Regards,
Michał Mirosław
Bug#966692: stunnel4: FTBFS because of test hang
On Thu, Aug 06, 2020 at 03:10:55AM +0200, Michał Mirosław wrote:
> On Thu, Aug 06, 2020 at 02:39:42AM +0200, Michał Mirosław wrote:
> > On Thu, Aug 06, 2020 at 03:16:35AM +0300, Peter Pentchev wrote:
> > > On Thu, Aug 06, 2020 at 12:48:10AM +0200, Michał Mirosław wrote:
> > > > On Thu, Aug 06, 2020 at 12:29:36AM +0300, Peter Pentchev wrote:
> > > > > On Wed, Aug 05, 2020 at 10:52:31PM +0200, Michał Mirosław wrote:
> > > > [...]
> > > > > > Using print-debugging, I see that it stops at wait_for_child line
> > > > > > just
> > > > > > after printing the version. It seems that something is reaping the
> > > > > > child
> > > > > > before the main thread has a chance to wait for it.
> > > > >
> > > > > OK, so the only thing that comes to my mind now is that you may be
> > > > > hitting a crazy, crazy race between register_child() and
> > > > > child_reaper(),
> > > > > and I say "a crazy, crazy race", because the test has to (apparently
> > > > > reproducibly) receive the CHLD signal exactly between the check and
> > > > > the creation in register_child()'s first "$children{...} //= ...cv"
> > > > > statement.
> > > >
> > > > Well, there is nothing that prevents SIGCHLD arriving between fork() and
> > > > register_child(). You could test this with more confidence (though not
> > > > 100%-reliably) by putting 'exit 1' just at the start of ($pid == 0)
> > > > branch.
> > >
> > > Nah, the problem is not just "between fork() and register_child()".
> > > It really must arrive at a very specific moment in time, because
> > > the //= operations for setting $children{$pid}{cv} try to make sure that
> > > a new value is not set (that is, a new condition variable is not
> > > created) if there already is such an element in the array. So the race
> > > is indeed between the //= in register_child() and the //= in
> > > child_reaper() - that is, child_reaper() must be invoked (SIGCHLD must
> > > arrive) *during* the execution of the //= in register_child().
> > >
> > > Unless I'm missing something, which is not at all out of the question :)
> >
> > The assignment seems not to be at fault (see last strace). I don't know
> > perl's
> > internals enough to say if this statement can be interrupted visibly by a
> > signal
> > handler (I would guess not a perl handler, though). There are two wait4()
> > calls
> > even before child_reaper has a chance to run.
>
> Another data point: this happens only with anyevent + libev and not with
> anyevent + libevent. The first is preferred and installed by default with
> libanyevent-perl, though.
>
> $ dpkg -l libanyevent-perl libev-perl | cat
> Desired=Unknown/Install/Remove/Purge/Hold
> | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
> |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
> ||/ Name Version Architecture Description
> +++----
> ii libanyevent-perl 7.140-3 amd64event loop framework with
> multiple implementations
> ii libev-perl 4.25-1 amd64Perl interface to libev, the
> high performance event loop
AnyEvent's doc [1] mentions that the framework installs (or just might?) it's
own SIGCHLD handler. Maybe there are just too many handlers for SIGCHLD?
[1] https://metacpan.org/pod/AnyEvent#SIGNALS
Best Regards,
Michał Mirosław
Bug#989103: pulseaudio crashes on startup
Package: pulseaudio Version: 14.2-2 Severity: grave Justification: renders package unusable X-Debbugs-Cc: mirq-debo...@rere.qmqm.pl After upgrade to bullseye, pulseaudio crashes on startup in pa_alsa_sink_new() -> find_mixer() due to mapping==NULL. The code at upstream's HEAD seems to assume that (element != NULL) implies (mapping != NULL). Program received signal SIGSEGV, Segmentation fault. 0x7286d85c in find_mixer (ignore_dB=false, element=0x5566dfe0 "Wave", mapping=0x0, u=0x556709b0) at modules/alsa/alsa-sink.c:2110 2110modules/alsa/alsa-sink.c: No such file or directory. (gdb) bt #0 0x7286d85c in find_mixer (ignore_dB=false, element=0x5566dfe0 "Wave", mapping=0x0, u=0x556709b0) at modules/alsa/alsa-sink.c:2110 #1 find_mixer (u=0x556709b0, mapping=0x0, element=0x5566dfe0 "Wave", ignore_dB=) at modules/alsa/alsa-sink.c:2098 #2 0x72871d14 in pa_alsa_sink_new (m=m@entry=0x5566b070, ma=ma@entry=0x55582990, driver=driver@entry=0x72895618 "modules/alsa/module-alsa-sink.c", card=card@entry=0x0, mapping=, mapping@entry=0x0) at modules/alsa/alsa-sink.c:2586 #3 0x72894347 in module_alsa_sink_LTX_pa__init (m=0x5566b070) at modules/alsa/module-alsa-sink.c:102 #4 0x77e30279 in pa_module_load (module=module@entry=0x7fffce40, c=c@entry=0x555761d0, name=name@entry=0x5566a820 "module-alsa-sink", argument=0x55669570 "device=hw:1,0 control=Wave") at pulsecore/module.c:191 #5 0x77e1c36c in pa_cli_command_load (c=0x555761d0, t=0x5566db00, buf=0x5556f0c0, fail=0x5556e5a5) at pulsecore/cli-command.c:437 #6 0x77e2429b in pa_cli_command_execute_line_stateful (c=c@entry=0x555761d0, s=s@entry=0x7fffcfa0 "load-module module-alsa-sink device=hw:1,0 control=Wave", buf=buf@entry=0x5556f0c0, fail=fail@entry=0x5556e5a5, ifstate=ifstate@entry=0x7fffcf9c) at pulsecore/cli-command.c:2141 #7 0x77e24a01 in pa_cli_command_execute_file_stream (c=c@entry=0x555761d0, f=f@entry=0x5556e980, buf=buf@entry=0x5556f0c0, fail=fail@entry=0x5556e5a5) at pulsecore/cli-command.c:2181 #8 0xb570 in main (argc=, argv=) at daemon/main.c:1105 -- Package-specific info: File '/etc/default/pulseaudio' does not exist -- System Information: Debian Release: 11.0 APT prefers testing APT policy: (900, 'testing'), (800, 'stable-debug'), (800, 'proposed-updates'), (800, 'stable'), (700, 'unstable'), (600, 'experimental'), (540, 'oldstable'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'proposed-updates-debug'), (1, 'experimental-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.12.6+ (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages pulseaudio depends on: ii adduser 3.118 ii init-system-helpers 1.60 ii libasound2 1.2.4-1.1 ii libasound2-plugins 1.2.2-2 ii libc62.31-12 ii libcap2 1:2.44-1 ii libdbus-1-3 1.12.20-2 ii libgcc-s110.2.1-6 ii libice6 2:1.0.10-1 ii libltdl7 2.4.6-15 ii liborc-0.4-0 1:0.4.32-1 ii libpulse014.2-2 ii libsm6 2:1.2.3-1 ii libsndfile1 1.0.31-1 ii libsoxr0 0.1.3-4 ii libspeexdsp1 1.2~rc1.2-1.1 ii libstdc++6 10.2.1-6 ii libsystemd0 247.3-5 ii libtdb1 1.4.3-1+b1 ii libudev1 247.3-5 ii libwebrtc-audio-processing1 0.3-1+b1 ii libx11-6 2:1.7.1-1 ii libx11-xcb1 2:1.7.1-1 ii libxcb1 1.14-3 ii libxtst6 2:1.2.3-1 ii lsb-base 11.1.0 ii pulseaudio-utils 14.2-2 Versions of packages pulseaudio recommends: ii dbus-user-session1.12.20-2 ii libpam-systemd [logind] 247.3-5 ii rtkit0.13-4 Versions of packages pulseaudio suggests: ii paprefs 1.1-2 ii pavucontrol 4.0-2 ii pavumeter0.9.3-4+b3 ii udev 247.3-5 -- Configuration Files: /etc/pulse/daemon.conf changed: ; daemonize = no ; fail = yes ; allow-module-loading = yes ; allow-exit = yes ; use-pid-file = yes ; system-instance = no ; local-server-type = user ; enable-shm = yes ; enable-memfd = yes ; shm-size-bytes = 0 # setting this 0 will use the system-default, usually 64 MiB ; lock-memory = no ; cpu-limit = no ; high-priority = yes ; nice-level = -11 ; realtime-scheduling = yes ; realtime-priority = 5 ; exit-idle-time = 20 ; scache-idle-time = 20 ; dl-search-path = (depends on
Bug#989103: pulseaudio crashes on startup
On Wed, May 26, 2021 at 10:19:31AM -0400, Felipe Sateler wrote:
> Control: tags -1 unreproducible moreinfo
>
>
> On Tue, May 25, 2021 at 10:27 PM Michał Mirosław
> wrote:
>
> > Package: pulseaudio
> > Version: 14.2-2
> > Severity: grave
> > Justification: renders package unusable
> > X-Debbugs-Cc: mirq-debo...@rere.qmqm.pl
> >
> > After upgrade to bullseye, pulseaudio crashes on startup in
> > pa_alsa_sink_new() -> find_mixer() due to mapping==NULL.
> >
>
> You have this in your config:
>
> load-module module-alsa-sink device=hw:1,0 control=Wave
>
> Does it crash if you remove that line?
Indeed this is the trigger.
load-module module-alsa-sink device=hw:1,0
works ok. Adding the mixer control name argument ("control=Wave" or
"control=Wave,0") makes pulseaudio segfault on startup. Guessing from
the documentation [1] version 14.0 had changes in code supporting this
case.
[1]
https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Modules/#module-alsa-sink
Best Regards
Michał Mirosław
Bug#989103: closed by Felipe Sateler (DMO is not supported)
On Thu, Jul 29, 2021 at 12:57:03PM +, Debian Bug Tracking System wrote: > Date: Thu, 29 Jul 2021 08:51:50 -0400 > From: Felipe Sateler > To: 989103-d...@bugs.debian.org, 991337-d...@bugs.debian.org > Subject: DMO is not supported > > deb-multimedia.org is not supported here. Please ask the maintainers of > that repository for support. Closing the bug. The bug is in bullseye package. I'm not sure where deb-multimedia came from? (It's not enabled in my sources.list) Best Regards Michał Mirosław
Bug#989103: closed by Felipe Sateler
On Thu, Jul 29, 2021 at 09:34:58AM -0400, Felipe Sateler wrote:
> Control: found -1 14.2-2
> Control: fixed -1 14.99-1
>
> Hi Michał!
>
> On Thu, Jul 29, 2021 at 9:27 AM Michał Mirosław
> wrote:
>
> > On Thu, Jul 29, 2021 at 12:57:03PM +, Debian Bug Tracking System wrote:
> > > Date: Thu, 29 Jul 2021 08:51:50 -0400
> > > From: Felipe Sateler
> > > To: 989103-d...@bugs.debian.org, 991337-d...@bugs.debian.org
> > > Subject: DMO is not supported
> > >
> > > deb-multimedia.org is not supported here. Please ask the maintainers of
> > > that repository for support. Closing the bug.
> >
> > The bug is in bullseye package. I'm not sure where deb-multimedia came
> > from?
> > (It's not enabled in my sources.list)
> >
>
> Sorry, I got confused by the last message from Keith Edmunds[1].
>
> On a more detailed look, this is fixed in experimental but not on
> bullseye. Help with an update for bullseye would be appreciated.
Hi, it looks the fix should be straightforward. Attached patch against
commit 9d29651ad4770 of https://salsa.debian.org/pulseaudio-team/pulseaudio.git
Best Regards
Michał Mirosław
commit 3d7e9a3689141ad81faaf756367247fe0ec6d446
Author: Michał Mirosław
Date: Sat Oct 9 02:54:17 2021 +0200
fix #989103
diff --git a/debian/changelog b/debian/changelog
index a1de8e162c47..77f6d4e41b7f 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,4 +1,6 @@
-pulseaudio (14.2-3) UNRELEASED; urgency=medium
+pulseaudio (14.2-3) bullseye; urgency=medium
+
+ * Backport commit 79cb1369 from upstream. (Closes: #989103)
[ Kevin Locke ]
* Move shell completion scripts to pulseaudio-utils.
diff --git a/debian/patches/fix-control-module-param.patch b/debian/patches/fix-control-module-param.patch
new file mode 100644
index ..6cdeb9f0de31
--- /dev/null
+++ b/debian/patches/fix-control-module-param.patch
@@ -0,0 +1,46 @@
+From 79cb1369fc4d22966cb65253e9da2ccda2f25b45 Mon Sep 17 00:00:00 2001
+From: "Igor V. Kovalenko"
+Date: Mon, 7 Jun 2021 08:53:24 +0300
+Subject: [PATCH] alsa-mixer: check if mapping is NULL before using it
+
+Fix Debian bullseye bug where adding this line makes pulseaudio crash on startup
+
+`load-module module-alsa-sink device=hw:1,0 control=Wave`
+
+See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989103
+
+Fixes: dacfcbb09 ("alsa-ucm: use the proper mixer name for ucm pcm sink/source")
+Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/576>
+---
+ src/modules/alsa/alsa-sink.c | 3 ++-
+ src/modules/alsa/alsa-source.c | 3 ++-
+ 2 files changed, 4 insertions(+), 2 deletions(-)
+
+diff --git a/src/modules/alsa/alsa-sink.c b/src/modules/alsa/alsa-sink.c
+index f7fef8a7e144..84cdb15c7318 100644
+--- a/src/modules/alsa/alsa-sink.c
b/src/modules/alsa/alsa-sink.c
+@@ -2107,7 +2107,8 @@ static void find_mixer(struct userdata *u, pa_alsa_mapping *mapping, const char
+ u->mixers = pa_hashmap_new_full(pa_idxset_string_hash_func, pa_idxset_string_compare_func,
+ NULL, (pa_free_cb_t) pa_alsa_mixer_free);
+
+-mdev = pa_proplist_gets(mapping->proplist, "alsa.mixer_device");
++if (mapping)
++mdev = pa_proplist_gets(mapping->proplist, "alsa.mixer_device");
+ if (mdev) {
+ u->mixer_handle = pa_alsa_open_mixer_by_name(u->mixers, mdev, true);
+ } else {
+diff --git a/src/modules/alsa/alsa-source.c b/src/modules/alsa/alsa-source.c
+index 76370f8faec7..083f92873ef5 100644
+--- a/src/modules/alsa/alsa-source.c
b/src/modules/alsa/alsa-source.c
+@@ -1813,7 +1813,8 @@ static void find_mixer(struct userdata *u, pa_alsa_mapping *mapping, const char
+ u->mixers = pa_hashmap_new_full(pa_idxset_string_hash_func, pa_idxset_string_compare_func,
+ NULL, (pa_free_cb_t) pa_alsa_mixer_free);
+
+-mdev = pa_proplist_gets(mapping->proplist, "alsa.mixer_device");
++if (mapping)
++mdev = pa_proplist_gets(mapping->proplist, "alsa.mixer_device");
+ if (mdev) {
+ u->mixer_handle = pa_alsa_open_mixer_by_name(u->mixers, mdev, false);
+ } else {
diff --git a/debian/patches/series b/debian/patches/series
index 54c06fdd4932..c8406a385b80 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,2 +1,3 @@
disable-autospawn.patch
tests-fix-use-of-uninitialized-variable-cpu_info.patch
+fix-control-module-param.patch
