On 04/08/2015 12:14, [email protected] wrote: > Alan McKinnon <[email protected]> wrote: > >> On 04/08/2015 11:13, [email protected] wrote: >>> Hi. After upgrading to perl 5.22.0 which was a pain -- had to remove >>> all those virtuals -- I am now finding that a small perl program which >>> connects to a mysql database yields the following when it exits: >>> >>> *** Error in `perl': double free or corruption (!prev): 0x0000000001ed8610 >>> *** >>> ======= Backtrace: ========= >>> /lib64/libc.so.6(+0x71e4b)[0x7f59bc417e4b] >>> /lib64/libc.so.6(+0x7730e)[0x7f59bc41d30e] >>> /lib64/libc.so.6(+0x77afb)[0x7f59bc41dafb] >>> /usr/lib64/perl5/vendor_perl/5.22.0/x86_64-linux-thread-multi/auto/DBD/mysql/mysql.so(mysql_db_destroy+0x32)[0x7f59bb206602] >>> /usr/lib64/perl5/vendor_perl/5.22.0/x86_64-linux-thread-multi/auto/DBD/mysql/mysql.so(+0x1234d)[0x7f59bb21034d] >>> /usr/lib64/perl5/vendor_perl/5.22.0/x86_64-linux-thread-multi/auto/DBI/DBI.so(XS_DBI_dispatch+0xcc9)[0x7f59bb83e7a9] >>> /usr/lib64/libperl.so.5.22(Perl_pp_entersub+0x49b)[0x7f59bc81663b] >>> /usr/lib64/libperl.so.5.22(Perl_call_sv+0x36f)[0x7f59bc794b5f] >>> /usr/lib64/libperl.so.5.22(+0xda25f)[0x7f59bc81b25f] >>> /usr/lib64/libperl.so.5.22(Perl_sv_clear+0x740)[0x7f59bc81bc10] >>> /usr/lib64/libperl.so.5.22(Perl_sv_free2+0x5d)[0x7f59bc81be9d] >>> /usr/lib64/libperl.so.5.22(+0xb7298)[0x7f59bc7f8298] >>> /usr/lib64/libperl.so.5.22(Perl_mg_free+0x2e)[0x7f59bc7f8a4e] >>> /usr/lib64/libperl.so.5.22(Perl_sv_clear+0xae)[0x7f59bc81b57e] >>> /usr/lib64/libperl.so.5.22(Perl_sv_free2+0x5d)[0x7f59bc81be9d] >>> /usr/lib64/libperl.so.5.22(Perl_leave_scope+0xd51)[0x7f59bc84a411] >>> /usr/lib64/libperl.so.5.22(+0x52c56)[0x7f59bc793c56] >>> /usr/lib64/libperl.so.5.22(Perl_my_exit+0x3f)[0x7f59bc798d0f] >>> /usr/lib64/libperl.so.5.22(Perl_pp_exit+0x4a)[0x7f59bc857a6a] >>> /usr/lib64/libperl.so.5.22(Perl_runops_standard+0x16)[0x7f59bc80f316] >>> /usr/lib64/libperl.so.5.22(perl_run+0x2f9)[0x7f59bc79c369] >>> perl(main+0x149)[0x400e39] >>> /lib64/libc.so.6(__libc_start_main+0xf0)[0x7f59bc3c67b0] >>> perl(_start+0x29)[0x400e79] >>> ======= Memory map: ======== >>> >>> memory map ommitted, if it is needed I can reproduce. >>> >>> So, should I downgrade -- means removing all those virtuals again -- or >>> any other ideas would be appreciated. >>> >>> I am running the unstable gentoo, if you need more information, I can >>> include it. >>> >>> Thanks in advance for any suggestions. >>> >> >> >> did you run emerge @preserved-rebuild, revdep-rebuild and perl-cleaner >> after the upgrade? That stuff's easy to forget. >> >> > > I ran both perl-cleaner --reallyall and emerge @preserved-rebuild which > only rebuilt some haskall stuff. Perl cleaner had some problems, it > tried to rebuild some python packages which at the time (before I did > the complete update_) had some problems because of the 3.3 to 3.4 > change. So I just took the emerge line from the perl cleaner, ommitted > any package which was a hard blocker andran the rest -- about 186 > packages. I can try to rerun perl-cleaner if you think that would help > any, since I now have updated the world. >
I think running perl-cleaner --all as step 1 is wise. It shouldn't need to make any changes, but let's cover all the usual bases first, paying particular attention to any DBD/DBI stuff it might find that were not installed by portage. I am also curious why you have blockers and had to fiddle with virtuals - the same upgrade here was clean and portage just automatically did everything it needed. Do you have any package.* entry for perl stuff? grep -ir perl /etc/portage -- Alan McKinnon [email protected]
