After upgrading from DBD-mysql 2.9007 to 3.0002_p3, a local bugzilla installation running with mysql broke completely. I was able to isolate it with a simple test case which was failing under 3.0002_p3 and running fine with 2.9007. I will attach the script immediately after this comment. It was dying with the following errors. Out of memory! Out of memory! Callback called exit. Some version numbers: DBI-1.48 DBD-mysql-2.9007 perl-5.8.7-r1 gcc-3.4.4-r1 mysql-4.1.14 I would suggest not making 3.0002_p3 for a *long* time.
Created attachment 71351 [details] Test script for retrieving data from mysql (actually a query from bugzilla)
Created attachment 71352 [details] Test script for retrieving data from mysql (actually a query from bugzilla)
Created attachment 71353 [details] emerge --info
(In reply to comment #3) > Created an attachment (id=71353) [edit] > emerge --info > I toned down my CFLAGS and CXXFLAGS to "-march=pentium4 -Os -pipe" with no change whatsoever. 3.0002_p3 still fails.
I've got the same problem here. After changing the bugzilla installation to another server (with mysql v5.0.15) i can't get it running here. Bugzilla checksetup.pl shows an "out of memory!" error. The testscript shows the same "out of memory!" error. emerge --info System uname: 2.6.14-gentoo i686 Pentium III (Katmai) Gentoo Base System version 1.12.0_pre9 ccache version 2.4 [enabled] dev-lang/python: 2.4.2 sys-apps/sandbox: 1.2.13 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.1 sys-devel/libtool: 1.5.20 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=pentium3 -fomit-frame-pointer -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -march=pentium3 -fomit-frame-pointer -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig ccache distlocks sandbox sfperms strict" GENTOO_MIRRORS="ftp://pegasus.gfs" LANG="de_DE@euro" LC_ALL="de_DE@euro" LINGUAS="de" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://pegasus.gfs/gentoo-portage" USE="x86 7zip acpi aim alsa apache2 apm arts avi berkdb bitmap-fonts bzip2 ccache cgi clamav clamd cli command-args crypt curl curlwrappers discard-path eds elf emboss encode extensions fam foomaticdb force-cgi-redirect fortran ftp gd gdbm gif gmp gnome gnutls gpm graphicsmagick graphviz gs gstreamer gtk2 gzip http icp icq imagemagick imap imlib irc jabber jbig john jp2 jpeg jpeg2k kde ldap libclamav libg++ libwww lzo lzw mad mbox md5sum mhash mikmod mime mmx mng motif mp3 mpeg msn mysql mysqli nagios-dns nagios-game nagios-ntp nagios-ping nagios-ssh ncurses netpbm nfs nis nls nocd ntlm ogg oggvorbis opengl oscar oss pam pcre pdflib pear perl php png postgres python qt quicktime quotas rar readline samba sasl session silc slang smtp snmp sockets spell sse ssl svg symlink syslog tcpd test tetex threads tiff tokenizer tos truetype truetype-fonts type1-fonts udev unicode ups userlocales vhosts vorbis webdav wmf xml xml2 xmlrpc xmms xsl xv yahoo zip zlib linguas_de userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LDFLAGS
(In reply to comment #0) Just dropping in to comment that this version of DBD-mysql also broke my Maia Mailguard installation. Rolling back DBD-mysql resolved the issue.
I've also had problems with this release. 3.0002_p3 segfaults when used by zmaudit.pl (Zoneminder http://www.zoneminder.com). I was able to pin it down to the execute call within the following code excerpt. Within this call it segfaults after a few loops in a non-deterministic fashion. It works perfectly with the previous ebuild of DBD-mysql. +++ code excerpt my $db_monitors; my $sql1 = "select Id from Monitors order by Id"; my $sth1 = $dbh->prepare_cached( $sql1 ) or die( "Can't prepare '$sql1': ".$dbh->errstr() ); my $sql2 = "select Id, (unix_timestamp() - unix_timestamp(StartTime)) as Age from Events where MonitorId = ? order by Id"; my $sth2 = $dbh->prepare_cached( $sql2 ) or die( "Can't prepare '$sql2': ".$dbh->errstr() ); my $res = $sth1->execute() or die( "Can't execute: ".$sth1->errstr() ); while( my $monitor = $sth1->fetchrow_hashref() ) { Debug( "Found database monitor '$monitor->{Id}'" ); my $db_events = $db_monitors->{$monitor->{Id}} = {}; my $res = $sth2->execute( $monitor->{Id} ) or die( "Can't execute: ".$sth2->errstr() ); while ( my $event = $sth2->fetchrow_hashref() ) { $db_events->{$event->{Id}} = $event->{Age}; } Debug( "Got ".int(keys(%$db_events))." events\n" ); $sth2->finish(); } $sth1->finish(); +++
(In reply to comment #0) > I would suggest not making 3.0002_p3 for a *long* time. Oops... that's supposed to day "I would suggest not making 3.0002_p2 **stable** for a *long* time.
Hi, I have same problem with bugzilla-2.20/checksetup.pl See my bugreport at https://bugzilla.mozilla.org/show_bug.cgi?id=297649 Solution is to use v3.0002 (haven't tried myself yet): http://groups.google.com.au/group/netscape.public.mozilla.webtools/browse_thread/thread/df6c6e5468c47fd2/52e14738b3cf2080?lnk=raot&hl=en
(In reply to comment #9) > Hi, > I have same problem with bugzilla-2.20/checksetup.pl > See my bugreport at https://bugzilla.mozilla.org/show_bug.cgi?id=297649 > > Solution is to use v3.0002 (haven't tried myself yet): > http://groups.google.com.au/group/netscape.public.mozilla.webtools/browse_thread/thread/df6c6e5468c47fd2/52e14738b3cf2080?lnk=raot&hl=en Here are the release dates for the 3.0002 series. [DIR] DBD-mysql-3.0002/ 11-Jul-2005 09:46 - [DIR] DBD-mysql-3.0002_1/ 03-Aug-2005 19:47 - [DIR] DBD-mysql-3.0002_2/ 26-Sep-2005 16:15 - [DIR] DBD-mysql-3.0002_3/ 28-Sep-2005 11:46 - [DIR] DBD-mysql-3.0002_4/ 06-Nov-2005 13:40 - Can you report if downgrading to 3.0002 fixes the problem?
(In reply to comment #10) > > Here are the release dates for the 3.0002 series. > > [DIR] DBD-mysql-3.0002/ 11-Jul-2005 09:46 - > [DIR] DBD-mysql-3.0002_1/ 03-Aug-2005 19:47 - > [DIR] DBD-mysql-3.0002_2/ 26-Sep-2005 16:15 - > [DIR] DBD-mysql-3.0002_3/ 28-Sep-2005 11:46 - > [DIR] DBD-mysql-3.0002_4/ 06-Nov-2005 13:40 - > > Can you report if downgrading to 3.0002 fixes the problem? > I tried it myself and there are no problems with 3.0002. Can the dev who added 3.0002_p3 to portage mask it please and instead add 3.0002 which seems to work fine? From the Changelog: *DBD-mysql-3.0002_p3 (16 Oct 2005) 16 Oct 2005; Francesco Riosa <vivo@gentoo.org> -DBD-mysql-2.9006.ebuild, +DBD-mysql-3.0002_p3.ebuild: version bump and clean-up
Any news on the awaited ebuild? Thanks. ;-)
did _p4 fix these issues at all? Its at the threshold of being open to being unmasked, but I don't want to unmask if it still causes you problems. In bug 112281, it resolved issues with a spamassassin session with mysql, but i want to confirm that isn't a fluke. thanks!
The testcase attached to this bug breaks with DBD-mysql-3.0002_p4. The testcase really works with plain 3.002 (the mysql-5.0-new_bit_type.patch does not apply cleanly, so I ometted that from my test). Please introduce the DBD-mysql-3.0002.ebuild.
3.0002 added to the tree, will mark stable in 30 days if there are no further reports against it
(In reply to comment #15) > 3.0002 added to the tree, will mark stable in 30 days if there are no further > reports against it > If anyone is still following this bug, I had good luck with dev-perl/DBD-mysql-3.0004 when I upgraded to it recently.
(In reply to comment #16) > If anyone is still following this bug, I had good luck with > dev-perl/DBD-mysql-3.0004 when I upgraded to it recently. > Yes, thanks!
3.004 works for me as well.
