Bug 475454 – >=dev-lang/perl-5.16 causes module Carp.pm to crash, when started from Pidgin with Perl plugin support. - #0 0x00007fffe5368a25 in Perl__invlist_union_maybe_complement_2nd () from /usr/lib64/libperl.so.5.16

• Status: RESOLVED TEST-REQUEST
• Product: Gentoo Linux

[Description Andrei Mihăilă 2013-07-01 19:55:52 UTC]

Pidgin crashes when started with any Perl plugin active. This started to happen after I upgraded to Perl 5.16.x ... which was a long time ago (and I admit I was too lazy to report it at that time). I did report it upstream (https://developer.pidgin.im/ticket/15377) - they said they don't know about any issue with Pidgin and Perl 5.16.x. Then I tested on an OpenSuse live CD with Perl 5.16.3 and it worked. So this seems to be related to Gentoo (most probably to some particular setting when building Perl or Pidgin with Perl support). 

How to reproduce:
1. Create a simple Pidgin Perl plugin that contains
##############
use Purple; 

our %PLUGIN_INFO = ( 
    perl_api_version => 2, 
    name             => "test", 
    load             => "test" 
); 

sub test() { 
} 
##############

Save the code into a file under ~/.purple/plugins say ... ~/.purple/plugins/test.pl and restart Pidgin and activate the plugin. It should crash either now either when restarting it after the plugin activation ... 

Another plugin example can be downloaded from here http://gitorious.org/libpurple-kwallet-plugin/libpurple-kwallet-plugin/blobs/master/libpurple_kwallet_plugin.pl - it saves the Pidgin accounts passwords into KWallet. It is the reason I want Pidgin Perl plugins to work - this plugin is useful to me (... should also mention that I've written it myself). To get it just do 

####
cd ~/.purple/plugins && wget http://gitorious.org/libpurple-kwallet-plugin/libpurple-kwallet-plugin/blobs/master/libpurple_kwallet_plugin.pl
####

and restart Pidgin. Activate the plugin and it should crash (or on the next Pidgin restart) ... 


After a discussion on the forum http://forums.gentoo.org/viewtopic-t-962444-highlight-pidgin+perl.html I tested with 5.12.5 and it works. Will test with 5.14.x if needed (they were hard-masked).

You can also find a backtrace where I initially reported the bug (upstream) https://developer.pidgin.im/ticket/15377 .

[Comment 1 Andrei Mihăilă 2013-07-01 20:01:19 UTC]

Created attachment 352422 [details]
Pidgin backtrace when it crashes with the Perl plugin

[Comment 2 Jeroen Roovers (RETIRED) 2013-07-02 15:31:05 UTC]

You probably need to run perl-cleaner...

*** This bug has been marked as a duplicate of bug 247315 ***

[Comment 3 Andrei Mihăilă 2013-07-02 15:36:50 UTC]

(In reply to Jeroen Roovers from comment #2)
> You probably need to run perl-cleaner...
> 
> *** This bug has been marked as a duplicate of bug 247315 ***

Did run perl-cleaner (sorry, only mentioned it in the forum post  - did a perl-cleaner --reallyall) with no result, the issue is still there.

[Comment 4 Kent Fredric (IRC: kent\n) (RETIRED) 2013-07-03 04:37:00 UTC]

23:23:06) plugins: /usr/lib64/purple-2/libjabber.so is not usable because the 'purple_init_plugin' symbol could not be found

^ suggests its a compile time issue.

So try recompiling/reinstalling pidgin, and if that still fails, please attach a copy of your pidgin build log. 

If recompiling pidgin solves the issue, then its a case of why perlcleaner didn't detect it needing reinstalled.

[Comment 5 Andrei Mihăilă 2013-07-03 19:52:01 UTC]

Created attachment 352546 [details]
Log of emerge -1 pidgin

Compiled perl 5.16.3 and then ran something like perl-cleaner --reallyall -- --keep-going -v > perl-cleaner.log 2>&1. Pidgin still crashes with roughly the same backtrace. The perl-cleaner.log is 4.4M ... won't attach all of that - just the list of packages it emerged (pidgin was included). Re-emerged pidgin, attached the log of that.

[Comment 6 Andrei Mihăilă 2013-07-03 19:52:35 UTC]

Created attachment 352548 [details]
List of packages emerged by perl-cleaner

[Comment 7 Tom Wijsman (TomWij) (RETIRED) 2013-07-09 17:40:55 UTC]

Okay, thank you for running those commands and confirming; assigned to Perl herd.

[Comment 8 Kent Fredric (IRC: kent\n) (RETIRED) 2013-07-10 01:54:20 UTC]

Searching has dug up this: http://mail-archives.apache.org/mod_mbox/perl-modperl/201208.mbox/[e-mail]6%3E 

Suggesting it could be a specific regular expression in Carp ( at least, that is what causes a similar problem on mod_perl )

If you can reduce the test code to something that fails the same way without 'use Purple', that would be incredibly helpful, because I'm a little short on knowing how to diagnose this sort of problem.

[Comment 9 Andrei Mihăilă 2013-07-11 19:11:54 UTC]

Yes, I found that page too - the suggestion might be correct. The problem is I can't make the perl interpreter crash when run from a command line (the issue only appears when starting Pidgin with a perl module activated). The problem seems to be in /usr/lib64/purple-2/perl/Purple.pm - a module that exports some functions from purple.so (really don't know anything about the way that is done). I tried modifying it - removed the 'use Carp;' line and replaced the 'croak' invocations with 'die'. I'm getting roughly the same backtrace. If I remove more of the code there I get an assertion_failed, but I don't think that helps. Also compiled perl with USE="debug" (and ran perl-cleaner afterwards as instructed by the perl ebuild) - nothing helpful unfortunately.

Have you been able to reproduce the bug based on my instructions?

[Comment 10 Kent Fredric (IRC: kent\n) (RETIRED) 2013-07-12 13:37:41 UTC]

Yeah, it doesn't even require you load Purple to make it crash.

You can make it crash with as little as:

---

use strict;

use Carp;

--- 

Fails pretty hard :/ 

I don't know where to go from here, looks like upstreams problem. We might be lucky and find its fixed in 5.18.

As a reductionist set, this also fails under Pidgin, but not natively:
----

#!/usr/bin/env perl 

use strict;
use warnings;
use utf8;

BEGIN {
    package Carp;

    sub croak {

    }
    $INC{'Carp.pm'} = 1;
}

our %PLUGIN_INFO = ( 
    perl_api_version => 2, 
    name             => "test", 
    load             => "test" 
); 
sub IWillNeverRun() {
    my $arg;
    utf8::is_utf8($arg) or $arg =~ s/([[:cntrl:]]|[[:^ascii:]])/sprintf("\\x{%x}",ord($1))/eg;
}

sub test() { 
}

---

The important part to note is this is not a /runtime/ failure within perl, but a /compile/ time failure, ie: it crashes as soon as a file with that regular expression it it is sourced ( for some reason )

[Comment 11 Andrei Mihăilă 2013-07-12 14:23:41 UTC]

Finally reproduced! Thank you!

I remember I tested on OpenSuse with Perl 5.16 and my Pidgin plugin worked so it could be that they somehow fixed that there. Will try again when I have the chance and confirm this.

[Comment 12 Kent Fredric (IRC: kent\n) (RETIRED) 2013-07-12 20:15:20 UTC]

Created attachment 353168 [details]
Full backtrace info

Recompiled perl and pidgin with FEATURES="splitdebug compressdebug installsources keepwork" CFLAGS+="-O1 -ggdb3" 

Attached is full debug backtrace given. Though, it doesn't make more sense to me than it already did. 

The exact source in C where the segv is comming from: 

PERL_STATIC_INLINE SV*
S_invlist_clone(pTHX_ SV* const invlist)
{

    /* Return a new inversion list that is a copy of the input one, which is
     * unchanged */

    /* Need to allocate extra space to accommodate Perl's addition of a
     * trailing NUL to SvPV's, since it thinks they are always strings */
    SV* new_invlist = _new_invlist(invlist_len(invlist) + 1); ########## <----
    STRLEN length = SvCUR(invlist);

    PERL_ARGS_ASSERT_INVLIST_CLONE;

    SvCUR_set(new_invlist, length); /* This isn't done automatically */
    Copy(SvPVX(invlist), SvPVX(new_invlist), length, char);

    return new_invlist;
}

[Comment 13 Kent Fredric (IRC: kent\n) (RETIRED) 2013-07-12 23:21:57 UTC]

If you want a copy of my builds with debug for pidgin and perl, here are some quickpkgs

https://mega.co.nz/#F!B5gXjbLa!WE-UTkoJhhFDT7ziNYOg9A

[Comment 14 Andrei Mihăilă 2013-07-15 20:00:30 UTC]

Created attachment 353394 [details]
log of pidgin under OpenSuse 12.3

I can confirm the plugin works on Open Suse 12.3 Live KDE DVD (http://software.opensuse.org/123/en). It has perl 5.16.2 and pidgin 2.10.7. There were some issues on the first run (had to restart Pidgin) but my plugin and the code above that crash Pidgin in Gentoo worked (log of the issues before restarting Pidgin attached). Also did perl test.pl where test.pl contains
---

use strict;

use Carp;

--- 
... no problems.



linux@linux:~> perl -V
Summary of my perl5 (revision 5 version 16 subversion 2) configuration:
   
  Platform:
    osname=linux, osvers=3.4.6-2.10-default, 
archname=x86_64-linux-thread-multi
    uname='linux build35 3.4.6-2.10-default #1 smp thu jul 26 09:36:26 
utc 2012 (641c197) x86_64 x86_64 x86_64 gnulinux '
    config_args='-ds -e -Dprefix=/usr -Dvendorprefix=/usr 
-Dinstallusrbinperl -Dusethreads -Di_db -Di_dbm -Di_ndbm -Di_gdbm 
-Dd_dbm_open -Duseshrplib=true -Doptimize=-fmessage-length=0 -O2 -Wall 
-D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables 
-fasynchronous-unwind-tables -g -Wall -pipe  
-Accflags=-DPERL_USE_SAFE_PUTENV 
-Dotherlibdirs=/usr/lib/perl5/site_perl'
    hint=recommended, useposix=true, d_sigaction=define
    useithreads=define, usemultiplicity=define
    useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
    use64bitint=define, use64bitall=define, uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DPERL_USE_SAFE_PUTENV 
-fno-strict-aliasing -pipe -fstack-protector -D_LARGEFILE_SOURCE 
-D_FILE_OFFSET_BITS=64',
    optimize='-fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 
-fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -Wall 
-pipe',
    cppflags='-D_REENTRANT -D_GNU_SOURCE -DPERL_USE_SAFE_PUTENV 
-fno-strict-aliasing -pipe -fstack-protector'
    ccversion='', gccversion='4.7.2 20130108 [gcc-4_7-branch revision 
195012]', gccosandvers=''
    intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
    ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', 
lseeksize=8
    alignbytes=8, prototype=define
  Linker and Libraries:
    ld='cc', ldflags =' -L/usr/local/lib64 -fstack-protector'
    libpth=/lib64 /usr/lib64 /usr/local/lib64
    libs=-lm -ldl -lcrypt -lpthread
    perllibs=-lm -ldl -lcrypt -lpthread
    libc=/lib64/libc-2.17.so, so=so, useshrplib=true, libperl=libperl.so
    gnulibc_version='2.17'
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E 
-Wl,-rpath,/usr/lib/perl5/5.16.2/x86_64-linux-thread-multi/CORE'
    cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib64 
-fstack-protector'


Characteristics of this binary (from libperl): 
  Compile-time options: HAS_TIMES MULTIPLICITY PERLIO_LAYERS
                        PERL_DONT_CREATE_GVSV PERL_IMPLICIT_CONTEXT
                        PERL_MALLOC_WRAP PERL_PRESERVE_IVUV
                        PERL_USE_SAFE_PUTENV USE_64_BIT_ALL 
USE_64_BIT_INT
                        USE_ITHREADS USE_LARGE_FILES USE_LOCALE
                        USE_LOCALE_COLLATE USE_LOCALE_CTYPE
                        USE_LOCALE_NUMERIC USE_PERLIO USE_PERL_ATOF
                        USE_REENTRANT_API
  Built under linux
  Compiled at Jan 26 2013 22:01:51
  @INC:
    /usr/lib/perl5/site_perl/5.16.2/x86_64-linux-thread-multi
    /usr/lib/perl5/site_perl/5.16.2
    /usr/lib/perl5/vendor_perl/5.16.2/x86_64-linux-thread-multi
    /usr/lib/perl5/vendor_perl/5.16.2
    /usr/lib/perl5/5.16.2/x86_64-linux-thread-multi
    /usr/lib/perl5/5.16.2
    /usr/lib/perl5/site_perl/5.16.2/x86_64-linux-thread-multi
    /usr/lib/perl5/site_perl/5.16.2
    /usr/lib/perl5/site_perl
    .




Pidgin 2.10.7 (libpurple 2.10.7)
unknown

Build Information
  Arguments to ./configure:   '--host=x86_64-suse-linux-gnu' 
'--build=x86_64-suse-linux-gnu' '--program-prefix=' '--prefix=/usr' 
'--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' 
'--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' 
'--libdir=/usr/lib64' '--libexecdir=/usr/lib' '--localstatedir=/var' 
'--sharedstatedir=/usr/com' '--mandir=/usr/share/man' 
'--infodir=/usr/share/info' '--disable-dependency-tracking' 
'--disable-static' '--disable-schemas-install' '--enable-plugins' 
'--enable-cyrus-sasl' '--disable-mono' '--enable-gstreamer' 
'--enable-nm' '--enable-dbus' '--enable-devhelp' '--disable-vv' 
'--with-tclconfig=/usr/lib64' '--with-tkconfig=/usr/lib64' 
'--with-system-ssl-certs=/etc/ssl/certs' 
'build_alias=x86_64-suse-linux-gnu' 'host_alias=x86_64-suse-linux-gnu' 
'CFLAGS=-fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 
-fstack-protector -funwind-tables -fasynchronous-unwind-tables -g 
-fstack-protector -fPIC' 'LDFLAGS=-pie'
  Print debugging messages: No
  Plugins: Enabled
  SSL: SSL support is present.

  Library Support
    Cyrus SASL: Enabled
    D-Bus: Enabled
    Evolution Addressbook: Disabled
    Gadu-Gadu library (libgadu): Enabled
    GtkSpell: Enabled
    GnuTLS: Enabled
    GStreamer: Enabled
    Mono: Disabled
    NetworkManager: Enabled
    Network Security Services (NSS): Enabled
    Perl: Enabled
    Tcl: Enabled
    Tk: Enabled
    UTF-8 DNS (IDN): Enabled
    Voice and Video: Disabled
    X Session Management: Enabled
    XScreenSaver: Enabled
    Zephyr library (libzephyr): Internal
    Zephyr uses Kerberos: No

[Comment 15 Andrei Mihăilă 2013-07-15 20:03:22 UTC]

Also I must say that the version of Perl that I have installed in Gentoo (5.16.3) doesn't crash with
---

use strict;

use Carp;

--- 

However the Pidgin plugin with the code provided by Kent Fredric does crash it.

[Comment 16 Mikle Kolyada (RETIRED) 2014-03-21 11:33:34 UTC]

Try with dev-lang/perl-5.18.2 please. And reopen if problem still present (just can't check it).

[Comment 17 Andrei Mihăilă 2014-03-24 21:07:59 UTC]

Unfortunately the bug is still there (for me at least). Installed perl 5.18.2 then ran perl-cleaner --reallyall (that didn't rebuild Pidgin but I did it manually). The code provided by Kent Frederic behaves the same as before ("fails under Pidgin, but not natively"). Here is the (truncated) backtrace:

---
(22:52:25) plugins: probing /home/mad/.purple/plugins/test.pl
pidgin: regcomp.c:7577: Perl__invlist_union_maybe_complement_2nd: Assertion `a != b' failed.

Program received signal SIGABRT, Aborted.
0x00007ffff476f249 in raise () from /lib64/libc.so.6
(gdb) bt
#0  0x00007ffff476f249 in raise () from /lib64/libc.so.6
#1  0x00007ffff47705a8 in abort () from /lib64/libc.so.6
#2  0x00007ffff4768386 in ?? () from /lib64/libc.so.6
#3  0x00007ffff4768432 in __assert_fail () from /lib64/libc.so.6
#4  0x00007fffe7bb2d95 in Perl__invlist_union_maybe_complement_2nd () from /usr/lib64/libperl.so.5.18
#12 0x00007fffe7bd2bfc in Perl_re_op_compile () from /usr/lib64/libperl.so.5.18
#13 0x00007fffe7b57bf7 in Perl_pmruntime () from /usr/lib64/libperl.so.5.18
#14 0x00007fffe7b9fa3d in Perl_yyparse () from /usr/lib64/libperl.so.5.18
(gdb)
---



With my plugin the (truncated) backtrace is:

---
(22:46:40) plugins: probing /home/mad/.purple/plugins/libpurple_kwallet_plugin.pl
(22:46:43) perl: Loading perl script
pidgin: inline_invlist.c:60: S__invlist_len: Assertion `invlist' failed.

Program received signal SIGABRT, Aborted.
0x00007ffff476f249 in raise () from /lib64/libc.so.6
(gdb) bt
#0  0x00007ffff476f249 in raise () from /lib64/libc.so.6
#1  0x00007ffff47705a8 in abort () from /lib64/libc.so.6
#2  0x00007ffff4768386 in ?? () from /lib64/libc.so.6
#3  0x00007ffff4768432 in __assert_fail () from /lib64/libc.so.6
#4  0x00007fffe7b3b962 in ?? () from /usr/lib64/libperl.so.5.18
#5  0x00007fffe7bb1762 in Perl__invlist_intersection_maybe_complement_2nd () from /usr/lib64/libperl.so.5.18
#16 0x00007fffe7bd2bfc in Perl_re_op_compile () from /usr/lib64/libperl.so.5.18
#17 0x00007fffe7b57bf7 in Perl_pmruntime () from /usr/lib64/libperl.so.5.18
#18 0x00007fffe7b9fa3d in Perl_yyparse () from /usr/lib64/libperl.so.5.18
---

[Comment 18 Mikle Kolyada (RETIRED) 2014-07-11 20:56:47 UTC]

Finally :D try 5.20 Just not sure about the bug

[Comment 19 Andrei Mihăilă 2014-09-30 08:33:59 UTC]

It works :-), thank you (and sorry for then long delay)! Will test on some other machines in the next few days (when I get to them). But it should be fine.