Bug#525534: *** glibc detected *** /usr/bin/perl: double free or corruption

[Niko Tyni]

reassign 525534 libgtk2-mozembed-perl 0.08-1
retitle 525534 libgtk2-mozembed-perl: FTBFS: *** glibc detected *** /usr/bin/perl: double free or corruption
severity 525534 serious
thanks

On Sat, Apr 25, 2009 at 03:10:13PM +0300, Niko Tyni wrote:
> On Sat, Apr 25, 2009 at 12:23:29PM +0200, Kurt Roeckx wrote:
> > Package: perl
> > Version: 5.10.0-19
> > Severity: important
>  
> > When building the libgtk2-mozembed-perl 0.08-1 package,
> > various arches saw an error like this:
> > t/GtkMozEmbed....Xlib:  extension "RANDR" missing on display ":99.0".
> > *** glibc detected *** /usr/bin/perl: double free or corruption (out): 0x00002b364e552920 ***
> > ======= Backtrace: =========
> > /lib/libc.so.6[0x2b3645d4c1b8]
> > /lib/libc.so.6(cfree+0x76)[0x2b3645d4dcf6]
> > /usr/lib/libperl.so.5.10(perl_destruct+0x136d)[0x2b36453739fd]
> > /usr/bin/perl(main+0xb3)[0x400ce3]
> > /lib/libc.so.6(__libc_start_main+0xe6)[0x2b3645cf85a6]
> > /usr/bin/perl[0x400b69]
> 
> As Gtk2::MozEmbed isn't pure Perl but an XS module, the bug can well be
> in its C parts. It's a bit early to blame Perl itself.
> 
> I'll have a look though.

Despite trying quite hard I'm not able to reproduce this on amd64.
I've tried with and without xvfb, inside pbuilder and sbuild chroots
and on a normal system, with and without debugperl etc.

I have also compared the buildd logs with my local ones, and the only
difference I can find is that some packages are pre-installed on the
buildds and I can't tell which version they are at. A possible explanation
could be that one those is outdated.

However, no luck there: the only extra packages that are pre-installed on
all the failing buildds are libpng12-0 and libpcre3, and only the first
one has been updated in the last few months. Moreover, libpng12-dev is
pulled in everywhere and its dependencies guarantee that libpng12-0 is
at the latest version.

The only difference I can think of is kernel versions. My tests are
with a Xen installation on an Etch dom0 (2.6.18-6-xen-amd64) and in a
sid chroot of a Lenny OpenVZ system (2.6.26-2-openvz-amd64). However,
I doubt that there's any consistency with the buildd kernels.

I'm reassigning this to the failing package itself, libgtk2-mozembed-perl.
Given things like

#if !GTK_MOZ_EMBED_CHECK_VERSION (1, 7, 3)
        /* To avoid getting a segfault, add an additional ref so that the thing
           will never get destroyed. */
        if (RETVAL)
                gtk_widget_ref (RETVAL);
#endif

in xs/GtkMozEmbed.xs, I doubt this is a general Perl problem.

If somebody can reproduce this, I'd be interested in the output of

 debugperl -Iblib/lib -Iblib/arch -DDo GtkMozEmbed.t

and any other details like whether the somewhat suspicious-looking
debian/patches/use-the-right-xul changes affect this.

My guess is that this is something like #317058: reference loops cause
global destruction happen in an undefined order, and one of those causes
the crash.

BTW, the test suite pollutes ~/.Schmuh. Maybe debian/rules should
run it with HOME set to /nonexistent or somesuch.

Cheers,
-- 
Niko Tyni   ntyni at debian.org