View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000618 | MySQL v5 for OS/2 & eComStation | Bug | public | 2014-07-24 19:04 | 2022-05-14 06:41 |
| Reporter | emax | Assigned To | Steven Levine | ||
| Priority | normal | Severity | crash | Reproducibility | sometimes |
| Status | resolved | Resolution | unable to reproduce | ||
| Platform | PC/eCS | OS | eCS | OS Version | 2.1 |
| Summary | 0000618: Mysql (5.1.72) sometimes exit unexpectly with the error details in description | ||||
| Description | InnoDB: Page number (if soted to page already) 0, InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 0 InnoDB: Page may be a file space header page 140711 7:32:58InnoDB: Error trying to access a stray pointer 0xa1747ff8 InnoDB: buf pool start is at 0x21034000, end at 0x27034000 InnoDB: Probable reason is database corruption or memory InnoDB: corruption. If this happens in an InnoDB database recovery, see InnoDB: http://dev...... 140711 7:32:58 InnoDB: Assertion failure in thread 662172064 in file ../../storage/innobase/include/buf0buf.ic line 264 InnoDB: We intentionally generate a memory trap. InnoDB: Submit a detailed report to http://bugs..... etc.. Killed by SIGABRT pid=0x6860 ppid=0x685e tid=0x0019 slot=0x0064 pri=0x200 mc=0x0001 X:\MYSQL\BIN\MYSQLD.EXE Process dumping was disabled, use DUMPPROC / PROCDUMP to enable it. | ||||
| Additional Information | [client] compress user=root [mysqld] user=mysql server-id=212528 basedir=X:/mysql datadir=X:/mysql/data innodb_buffer_pool_size = 256M max_connections=500 | ||||
| Tags | No tags attached. | ||||
|
|
Without evidence to the contrary, this looks like database corruption. The offending pointer 0xa1747ff8 is well outside the maximum buffer pool size. The buffer pool usage is: [j:\tmp]rexxtry numeric digits 15 ; say x2d(27034000) - x2d(21034000) 100663296 The 100,663,296 bytes is well below the buffer pool size limit. There's noting in what we have seen so far that indicates any sort of out of memory or out of semaphores problem. FWIW, a google for buf0buf.ic line 264 indicates that this is a relatively well known failure mode, but there's nothing that seems related to your specific failure. If you have a process dump fo the failure, perhaps it will tell us a bit more about what the server was doing when the errant pointer came to be. |
|
|
unfortunately no exceptq dumps at 7:32 in the morning when mysql has quit unexpectly i've dumps only when i quit mysql at night with a script for bkups massimo |
|
|
HI finally got around to checking source today. Exceptq support was not enabled in mysqld.cc I added it this evening and the result is: http://smedley.id.au/tmp/mysql-5.1.72-20140725.zip Needs pthr01.dll |
|
|
mysql upgraded |
|
|
mysql51.dll requires gcc491. Got a link? Theseus confirms that exceptq is loaded for the initial 3 threads. |
|
|
new build of mysql use these libraries (of course except standard ecs libs as sesmgr, kbdcalls, doscall1 etc.): GCC473.DLL 22.288 bytes 31/01/14 date LIBC065.DLL 1.312 Kbytes 23/03/12 date PTHR01.DLL 7.879 bytes 25/04/14 date are these the right libraries? thanks massimo |
|
|
i had an "exit" or crash (i don't know) of mysql, with no dump of any kind (after updating to the latest version i've disabled Z3 env. on this server) massimo |
|
|
I had similar problems a few months ago. That was before excerptq was enabled. Silent crashes started after the new releases of Moodle switched to Innodb. Trying to fix the "corrupted" database didn't help. After moving all the Innodb databases to a windows server, they work without problems, and the os/2 server with only Myisam databases had no more crashes since. So my guess is that the databases weren't actually corrupted, and there is a problem with Innodb under os/2. I have Ecs 2.1 on a rather old Asus P4PE MB, single processor. |
|
|
i add these 2 "dumps": InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 0 InnoDB: Page may be a file space header page 140902 20:15:26InnoDB: Error: trying to access a stray pointer 0xa1757ff8 InnoDB: buf pool start is at 0x21034000, end at 0x27034000 InnoDB: Probable reason is database corruption or memory InnoDB: corruption. If this happens in an InnoDB database recovery, see InnoDB: http://dev.mysql.com/doc/refman/5.1/en/forcing-innodb-recovery.html InnoDB: how to force recovery. 140902 20:15:26 InnoDB: Assertion failure in thread 673392608 in file ../../sto rage/innobase/include/buf0buf.ic line 264 InnoDB: We intentionally generate a memory trap. InnoDB: Submit a detailed bug report to http://bugs.mysql.com. InnoDB: If you get repeated assertion failures or crashes, even InnoDB: immediately after the mysqld startup, there may be InnoDB: corruption in the InnoDB tablespace. Please refer to InnoDB: http://dev.mysql.com/doc/refman/5.1/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. Killed by SIGABRT pid=0x77c3 ppid=0x77c1 tid=0x0092 slot=0x027b pri=0x0200 mc=0x0001 D:\MYSQL\BIN\MYSQLD.EXE Process dumping was disabled, use DUMPPROC / PROCDUMP to enable it. 140904 2:24:57 InnoDB: Initializing buffer pool, size = 512.0M 140904 2:24:58 InnoDB: Completed initialization of buffer pool 140904 2:24:58 InnoDB: Started; log sequence number 0 505121309 UNIX Socket is \socket\MySQL 140904 2:24:59 [Note] Event Scheduler: Loaded 0 events 140904 2:24:59 [Note] D:\mysql\bin\mysqld.exe: ready for connections. Version: '5.1.72' socket: '\socket\MySQL' port: 3306 Source distribution 140904 20:19:53 InnoDB: Assertion failure in thread 678567520 in file btr/btr0b tr.c line 136 InnoDB: Failing assertion: (ibool)!!page_is_comp(root) == dict_table_is_comp(ind ex->table) InnoDB: We intentionally generate a memory trap. InnoDB: Submit a detailed bug report to http://bugs.mysql.com. InnoDB: If you get repeated assertion failures or crashes, even InnoDB: immediately after the mysqld startup, there may be InnoDB: corruption in the InnoDB tablespace. Please refer to InnoDB: http://dev.mysql.com/doc/refman/5.1/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. Killed by SIGABRT pid=0xbf2e ppid=0xbf2c tid=0x0081 slot=0x0249 pri=0x0200 mc=0x0001 D:\MYSQL\BIN\MYSQLD.EXE Process dumping was disabled, use DUMPPROC / PROCDUMP to enable it. |
|
|
Max, no .trp ? |
|
|
not for these 2 abnormal exits but i have them for other kinds sent in email thanks massimo |
|
|
Is this issue resolved with the latest httpd and libc builds? |
|
|
of course no |
|
|
Please test with a supported release and if this is still an issue, open a new ticket. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2014-07-24 19:04 | emax | New Issue | |
| 2014-07-25 00:20 | Steven Levine | Note Added: 0002784 | |
| 2014-07-25 06:41 | emax | Note Added: 0002785 | |
| 2014-07-25 23:56 | psmedley | Note Added: 0002786 | |
| 2014-07-26 00:24 | emax | Note Added: 0002787 | |
| 2014-07-26 00:24 | emax | Note Edited: 0002787 | |
| 2014-07-26 01:27 | Steven Levine | Note Added: 0002788 | |
| 2014-07-26 09:52 | emax | Note Added: 0002789 | |
| 2014-07-26 10:03 | emax | Note Edited: 0002789 | |
| 2014-07-30 09:10 | emax | Note Added: 0002790 | |
| 2014-08-13 22:50 | piesse | Note Added: 0002814 | |
| 2014-09-04 18:35 | emax | Note Added: 0002832 | |
| 2014-09-10 09:54 | psmedley | Note Added: 0002834 | |
| 2014-09-10 10:58 | emax | Note Added: 0002835 | |
| 2015-02-03 00:00 | Steven Levine | Note Added: 0003019 | |
| 2015-02-03 00:00 | Steven Levine | Assigned To | => Steven Levine |
| 2015-02-03 00:00 | Steven Levine | Status | new => feedback |
| 2015-02-03 09:04 | emax | Note Added: 0003020 | |
| 2015-02-03 09:04 | emax | Status | feedback => assigned |
| 2015-02-03 09:04 | emax | Note Edited: 0003020 | |
| 2022-05-14 06:41 | psmedley | Status | assigned => resolved |
| 2022-05-14 06:41 | psmedley | Resolution | open => unable to reproduce |
| 2022-05-14 06:41 | psmedley | Note Added: 0004252 |
