Ady, the assertion failure means that a transaction object to be freed was not in a committed or rolled back state.
Please try running your test as single-threaded, so that we see if this is something repeatable. In the ideal case you could point out the transaction which fails to do a commit or a rollback at the end. At a quick glance DROP TABLE, RENAME TABLE, and DROP DATABASE are suspect. Does the test contain these operations? Regards, Heikki http://www.innodb.com >SEND-PR: -*- send-pr -*- >SEND-PR: Lines starting with `SEND-PR' will be removed automatically, as >SEND-PR: will all comments (text enclosed in `<' and `>').SEND-PR: >From: [EMAIL PROTECTED]: [EMAIL PROTECTED] >Subject: mysql with innodb not reliable >Description: >011115 09:58:46 mysqld started011115 9:58:48 InnoDB: Started >/usr/sbin/mysqld: ready for connections >InnoDB: Assertion failure in thread 2031640 in file trx0trx.c line 178 >InnoDB: We intentionally generate a memory trap. >InnoDB: Send a detailed bug report to [EMAIL PROTECTED] got signal 11; >This could be because you hit a bug. It is also possible that this binary >or one of the libraries it was linked agaist is corrupt, improperly built, >or misconfigured. This error can also be caused by malfunctioning hardware. >We will try our best to scrape up some info that will hopefully help diagnose >the problem, but since we have already crashed, something is definitely wrong >and this may fail key_buffer_size=33550336record_buffer=131072 >sort_buffer=3145720max_used_connections=135max_connections=400 >threads_connected=57It is possible that mysqld could use up to >key_buffer_size + (record_buffer + sort_buffer)*max_connections = 1312760 K >bytes of memoryHope that's ok, if not, decrease some variables in the equation >Attempting backtrace. You can use the following information to find out >where mysqld died. If you see no messages after this, something went >terribly wrong...Stack range sanity check OK, backtrace follows:0x806cf16 >0x82517480x83267f00x80bb94fStack trace seems successful - bottom reached >Please read http://www.mysql.com/doc/U/s/Using_stack_trace.html and follow >instructions on how to resolve the stack trace. Resolved >stack trace is much more helpful in diagnosing the problem, so please do >resolve itTrying to get some variables. >Some pointers may be invalid and cause the dump to abort... >thd->query at (nil) is invalid pointerthd->thread_id=1976 >Successfully dumped variables, if you ran with --log, take a look at the >details of what thread 1976 did to cause the crash. In some cases of really >bad corruption, the values shown above may be invalid >The manual page at http://www.mysql.com/doc/C/r/Crashing.html contains >information that should help you find out what is causing the crash >Number of processes running now: 2mysqld process hanging, pid 4523 - killed >mysqld process hanging, pid 30183 - killed Number of processes running now: 1 >011115 10:36:41 mysqld restarted011115 10:36:41 mysqld ended >011115 10:36:42 mysqld endedmysqld process hanging, pid 12168 - killed >011115 10:36:42 mysqld restarted InnoDB: Database was not shut down normally. >InnoDB: Starting recovery from log files... >InnoDB: Starting log scan based on checkpoint at >InnoDB: log sequence number 0 111766857 >InnoDB: Doing recovery: scanned up to log sequence number 0 111832064 >InnoDB: Doing recovery: scanned up to log sequence number 0 111897600 >InnoDB: Doing recovery: scanned up to log sequence number 0 111963136 >InnoDB: Doing recovery: scanned up to log sequence number 0 112028672 >InnoDB: Doing recovery: scanned up to log sequence number 0 112094208 >InnoDB: Doing recovery: scanned up to log sequence number 0 112159744 >InnoDB: Doing recovery: scanned up to log sequence number 0 112225280 >InnoDB: Doing recovery: scanned up to log sequence number 0 112290816 >InnoDB: Doing recovery: scanned up to log sequence number 0 112356352 >InnoDB: Doing recovery: scanned up to log sequence number 0 112421888 >InnoDB: After this prints a line for every 10th scan sweep: >InnoDB: 2 uncommitted transaction(s) which must be rolled back >Trx id counter is 0 180736InnoDB: Starting rollback of uncommitted transactions >InnoDB: Rolling back trx with id 0 180386 >InnoDB: Rolling back of trx id 0 180737 completed >InnoDB: Rolling back trx with id 0 180385 >InnoDB: Rolling back of trx id 0 180385 completed>How-To-Repeat: > It happens when i have heavy load on my web, i use "ab" (apache >benchmarking) with -n 5 and -c 200 >Fix: I don't know :( >>Submitter-Id: ady>Originator: ady>Organization: > <organization of PR author (multiple lines)> >>MySQL support: [none | licence | email support | extended email support ] >>Synopsis: mysql with innodb not reliable >>Severity: <[ non-critical | serious | critical ] (one line)> >>Priority: <[ low | medium | high ] (one line)>>Category: mysql >>Class: <[ sw-bug | doc-bug | change-request | support ] (one line)> >>Release: mysql-3.23.44 (Official MySQL RPM ) >>Server: /usr/bin/mysqladmin Ver 8.22 Distrib 3.23.44, for pc-linux-gnu on i686 >Copyright (C) 2000 MySQL AB & MySQL Finland AB & TCX DataKonsult AB >This software comes with ABSOLUTELY NO WARRANTY. This is free software, >and you are welcome to modify and redistribute it under the GPL license >Server version 3.23.44Protocol version 10 >Connection Localhost via UNIX socket >UNIX socket /var/lib/mysql/mysql.sock >Uptime: 4 min 16 sec >Threads: 1 Questions: 18879 Slow queries: 0 Opens: 596 Flush tables: 1 >Open tables: 189 Queries per second avg: 73.746>Environment: > <machine, os, target, libraries (multiple lines)> >System: Linux agus.redhat.ebdesk.net 2.4.2-2 #1 Sun Apr 8 20:41:30 EDT 2001 >i686 unknownArchitecture: i686 >Some paths: /usr/bin/perl /usr/bin/make /usr/bin/gmake /usr/bin/gcc /usr/bin/cc >GCC: Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs >gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-81) >Compilation info: CC='gcc' CFLAGS=' -O3' CXX='gcc' CXXFLAGS=' -O3 > -felide-constructors -fomit-frame-pointer -fno-exceptions -fno-rtti > ' LDFLAGS=''LIBC: >lrwxrwxrwx 1 root root 13 Sep 17 17:25 /lib/libc.so.6 -> >libc-2.2.2.so >-rwxr-xr-x 1 root root 1236396 Apr 7 2001 /lib/libc-2.2.2.so >-rw-r--r-- 1 root root 26350254 Apr 7 2001 /usr/lib/libc.a >-rw-r--r-- 1 root root 178 Apr 7 2001 /usr/lib/libc.so >Configure command: ./configure --disable-shared >--with-mysqld-ldflags=-all-static --with-client-ldflags=-all-static >--with-innodb --with-berkeley-db --enable-assembler --with-mysqld-user=mysql >--with-unix-socket-path=/var/lib/mysql/mysql.sock --prefix=/ >--with-extra-charsets=complex --exec-prefix=/usr --libexecdir=/usr/sbin >--sysconfdir=/etc --datadir=/usr/share --localstatedir=/var/lib/mysql >--infodir=/usr/info --includedir=/usr/include --mandir=/usr/man --with-innodb >--with-berkeley-db '--with-comment=Official MySQL RPM ' >Here others information from my computer # uname -a >Linux agus.redhat.ebdesk.net 2.4.2-2 #1 Sun Apr 8 20:41:30 EDT 2001 i686 unknown > # free total used free shared buffers cached >Mem: 251564 249048 2516 0 5856 148224 >-/+ buffers/cache: 94968 156596Swap: 522064 63764 458300 ># dmesg | more >Linux version 2.4.2-2 ([EMAIL PROTECTED]) (gcc version 2.96 >20000731 (Red Hat Linux 7.1 2.96-79)) #1 Sun Apr 8 20:41:30 EDT 2001.... >hda: QUANTUM FIREBALL EX3.2A, ATA DISK drivehdb: SAMSUNG SV0322A, ATA DISK drive >hdd: IDE/ATAPI CD-ROM 52XS, ATAPI CD/DVD-ROM drive >ide0 at 0x1f0-0x1f7,0x3f6 on irq 14ide1 at 0x170-0x177,0x376 on irq 15 >hda: 6306048 sectors (3229 MB) w/418KiB Cache, CHS=782/128/63, UDMA(33) >hdb: 6250608 sectors (3200 MB) w/490KiB Cache, CHS=775/128/63, UDMA(33) >Partition check: hda: hda1 hda2 < hda5 hda6 > hdb: hdb1 hdb2 # df >Filesystem 1k-blocks Used Available Use% Mounted on >/dev/hda6 2797864 2197136 458604 83% / >/dev/hda1 42913 3485 37212 9% /boot >192.168.10.98:/home/ady > 19354752 5406996 12964580 30% /ady >/dev/hdb1 3075664 16872 2902556 1% /d # hdparm -t /dev/hda > /dev/hda: Timing buffered disk reads: 64 MB in 16.24 seconds = 3.94 MB/sec ># hdparm -t /dev/hda/dev/hda: > Timing buffered disk reads: 64 MB in 16.16 seconds = 3.96 MB/sec ># hdparm -t /dev/hda/dev/hda: > Timing buffered disk reads: 64 MB in 16.18 seconds = 3.96 MB/sec ># hdparm -T /dev/hda/dev/hda: > Timing buffer-cache reads: 128 MB in 3.27 seconds = 39.14 MB/sec ># hdparm -T /dev/hda/dev/hda:# cat /proc/cpuinfo processor : 0 >vendor_id : GenuineIntelcpu family : 6model : 7 >model name : Pentium III (Katmai)stepping : 3 >cpu MHz : 451.026cache size : 512 KBfdiv_bug : no >hlt_bug : nof00f_bug : nocoma_bug : no >fpu : yesfpu_exception : yescpuid level : 3 >wp : yes >flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov >pat pse36 mmx fxsr ssebogomips : 897.84 # cat /proc/meminfo > total: used: free: shared: buffers: cached: >Mem: 257601536 177344512 80257024 0 59408384 78409728 >Swap: 272457728 21614592 250843136MemTotal: 251564 kB >MemFree: 78376 kBMemShared: 0 kBBuffers: 58016 kB >Cached: 76572 kBActive: 130220 kBInact_dirty: 3768 kB >Inact_clean: 600 kBInact_target: 84 kBHighTotal: 0 kB >HighFree: 0 kBLowTotal: 251564 kBLowFree: 78376 kB >SwapTotal: 266072 kBSwapFree: 244964 kB-- ady -- >email: ady <at> ebdesk.com adiwicaksono <at> yahoo.com > ady <at> students.if.itb.ac.idhomepage: http://ady97.hypermart.net/ > --------------------------------------------------------------------- Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
