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 nt...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org