Re: Possible mass bug filing: embedding perl hangs on hppa without PERL_SYS_INIT3
On Wed, Aug 13, 2008 at 12:48:32PM +0200, Sebastian Harl wrote: > On Sun, Aug 10, 2008 at 10:59:38PM +0300, Niko Tyni wrote: > > as seen in #486069, since Perl 5.10.0, embedding Perl hangs on hppa > > in pthread_mutex_lock() inside perl_parse() if PERL_SYS_INIT3() hasn't > > been called. > > There are currently (at least) 26 source packages in unstable that > > produce binary packages linking against libperl5.10 on amd64 and whose > > .orig.tar.gz or .diff.gz matches /perl_parse/ but not /PERL_SYS_INIT3/. > > This sounds like a valid reason for mass bug filing to me. Thanks, done. The bugs can be seen at http://bugs.debian.org/cgi-bin/[EMAIL PROTECTED];tag=perl-sys-init3 -- Niko Tyni [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Possible mass bug filing: embedding perl hangs on hppa without PERL_SYS_INIT3
Hi, On Sun, Aug 10, 2008 at 10:59:38PM +0300, Niko Tyni wrote: > as seen in #486069, since Perl 5.10.0, embedding Perl hangs on hppa > in pthread_mutex_lock() inside perl_parse() if PERL_SYS_INIT3() hasn't > been called. > > The need for PERL_SYS_INIT3() has been documented in perlembed.pod since > Perl 5.8.1, so this is not a bug in perl. > > Quoting Carlos O'Donell in #486069: > > > The locked state of a lock is 0 on hppa, which means that if you don't > > initialize your locks (as documented), they begin in the locked state > > e.g. bss initialized to zero. > > > > You must use PERL_SYS_INIT3() on hppa, I don't know how it worked > > without it. > > There are currently (at least) 26 source packages in unstable that > produce binary packages linking against libperl5.10 on amd64 and whose > .orig.tar.gz or .diff.gz matches /perl_parse/ but not /PERL_SYS_INIT3/. This sounds like a valid reason for mass bug filing to me. > The packages have different ways of accessing the embedded perl > interpreter, and finding a way to verify the bug in each of them is pretty > time consuming. Particularly so because I don't have an hppa machine of > my own, and running for instance abiword over a slow network connection > is probably going to take quite a while. > > Is there enough evidence here to file the bugs without actually testing > for the lockup? If not, could somebody (from debian-hppa?) please take > the lead in testing them? Carlos O'Donell's explanation sounds like there should hardly be any false positives, so this should imho be fine. Cheers, Sebastian -- Sebastian "tokkee" Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin signature.asc Description: Digital signature
Possible mass bug filing: embedding perl hangs on hppa without PERL_SYS_INIT3
Hi debian-devel and debian-hppa, as seen in #486069, since Perl 5.10.0, embedding Perl hangs on hppa in pthread_mutex_lock() inside perl_parse() if PERL_SYS_INIT3() hasn't been called. The need for PERL_SYS_INIT3() has been documented in perlembed.pod since Perl 5.8.1, so this is not a bug in perl. Quoting Carlos O'Donell in #486069: > The locked state of a lock is 0 on hppa, which means that if you don't > initialize your locks (as documented), they begin in the locked state > e.g. bss initialized to zero. > > You must use PERL_SYS_INIT3() on hppa, I don't know how it worked > without it. There are currently (at least) 26 source packages in unstable that produce binary packages linking against libperl5.10 on amd64 and whose .orig.tar.gz or .diff.gz matches /perl_parse/ but not /PERL_SYS_INIT3/. I think this needs a mass bug filing, proposed usertag: User: [EMAIL PROTECTED] Usertags: perl-sys-init3 The diagnostic has been proven good by three packages (speedy-cgi-perl, eperl, pike7.6) where the bug was verified by failing builds or the like. The inn and inn2 packages were fixed after my debian-perl announcement in June. I think the severity for these bugs should be 'grave' for the wzdftpd-mod-perl binary package because it's unusable on hppa, and 'important' for the others. The packages have different ways of accessing the embedded perl interpreter, and finding a way to verify the bug in each of them is pretty time consuming. Particularly so because I don't have an hppa machine of my own, and running for instance abiword over a slow network connection is probably going to take quite a while. Is there enough evidence here to file the bugs without actually testing for the lockup? If not, could somebody (from debian-hppa?) please take the lead in testing them? I'm attaching a dd-list of the suspected packages. -- Niko Tyni [EMAIL PROTECTED] Davide Puricelli (evo) <[EMAIL PROTECTED]> xchat Masayuki Hatta (mhatta) <[EMAIL PROTECTED]> abiword Stefan Hornburg (Racke) <[EMAIL PROTECTED]> courier J.H.M. Dassen (Ray) <[EMAIL PROTECTED]> gnumeric Russ Allbery <[EMAIL PROTECTED]> openldap (U) Thomas Anders <[EMAIL PROTECTED]> net-snmp (U) Miroslaw L. Baran <[EMAIL PROTECTED]> epic4 Roland Bauerschmidt <[EMAIL PROTECTED]> openldap (U) Emmanuel Bouthenot <[EMAIL PROTECTED]> weechat (U) Marco Cabizza <[EMAIL PROTECTED]> xchat-gnome Pierre Chifflier <[EMAIL PROTECTED]> wzdftpd Debian GGZ Maintainers <[EMAIL PROTECTED]> ggz-grubby Debian GNOME Maintainers <[EMAIL PROTECTED]> xchat-gnome (U) Debian KDE Extras Team <[EMAIL PROTECTED]> kvirc Debian OpenLDAP Maintainers <[EMAIL PROTECTED]> openldap Debian Vim Maintainers <[EMAIL PROTECTED]> vim Mark W. Eichin <[EMAIL PROTECTED]> owl Peter Eisentraut <[EMAIL PROTECTED]> ggz-grubby (U) Zak B. Elep <[EMAIL PROTECTED]> opendchub Decklin Foster <[EMAIL PROTECTED]> rxvt-unicode Jochen Friedrich <[EMAIL PROTECTED]> net-snmp (U) Stephen Frost <[EMAIL PROTECTED]> openldap (U) Gerfried Fuchs <[EMAIL PROTECTED]> irssi (U) Stephen Gran <[EMAIL PROTECTED]> freeradius Pierre Habouzit <[EMAIL PROTECTED]> vim (U) Sam Hartman <[EMAIL PROTECTED]> barnowl Mark Hymers <[EMAIL PROTECTED]> freeradius (U) Joshua Kwan <[EMAIL PROTECTED]> abiword (U) Torsten Landschoff <[EMAIL PROTECTED]> openldap (U) Steve Langasek <[EMAIL PROTECTED]> openldap (U) Julien Louis <[EMAIL PROTECTED]> weechat Bart Martens <[EMAIL PROTECTED]> xchat (U) Christoph Martin <[EMAIL PROTECTED]> mimedefang Patrick Matthäi <[EMAIL PROTECTED]> znc Robert McQueen <[EMAIL PROTECTED]> pidgin Michael Mende <[EMAIL PROTECTED]> wackamole Noah Meyerhans <[EMAIL PROTECTED]> net-snmp (U) Loic Minier <[EMAIL PROTECTED]> xchat-gnome (U) Matthijs Mohlmann <[EMAIL PROTECTED]> openldap (U) Net-SNMP Packaging Team <[EMAIL PROTECTED]> net-snmp Brendan O'Dea <[EMAIL PROTECTED]> vile David Pashley <[EMAIL PROTECTED]> irssi Ari Pollak <[EMAIL PROTECTED]> pidgin (U) Frederik Schüler <[EMAIL PROTECTED]> wackamole (U) Benjamin Seidenberg <[EMAIL PROTECTED]> pork Raúl Sánchez Siles <[EMAIL PROTECTED]> kvirc (U) Josef Spillner <[EMAIL PROTECTED]> ggz-grubby (U) Paul van Tilburg <[EMAIL PROTECTED]> vile (U) Norbert Tretkowski <[EMAIL PROTECTED]> xchat-gnome (U) James Vega <[EMAIL PROTECTED]> vim (U) NIIBE Yutaka <[EMAIL PROTECTED]> golly Stefano Zacchiroli <[EMAIL PROTECTED]> vim (U)
