View Issue Details

IDProjectCategoryView StatusLast Update
0000618MySQL v5 for OS/2 & eComStationBugpublic2021-07-25 11:35
ReporteremaxAssigned ToSteven Levine 
PrioritynormalSeveritycrashReproducibilitysometimes
Status assignedResolutionopen 
PlatformPC/eCSOSeCSOS Version2.1
Product Version 
Target VersionFixed in Version 
Summary0000618: Mysql (5.1.72) sometimes exit unexpectly with the error details in description
DescriptionInnoDB: 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
TagsNo tags attached.

Activities

Steven Levine

2014-07-25 09:50

manager   ~0002784

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.

emax

2014-07-25 16:11

reporter   ~0002785

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

psmedley

2014-07-26 09:26

administrator   ~0002786

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

emax

2014-07-26 09:54

reporter   ~0002787

Last edited: 2014-07-26 09:54

View 2 revisions

mysql upgraded

Steven Levine

2014-07-26 10:57

manager   ~0002788

mysql51.dll requires gcc491. Got a link?

Theseus confirms that exceptq is loaded for the initial 3 threads.

emax

2014-07-26 19:22

reporter   ~0002789

Last edited: 2014-07-26 19:33

View 2 revisions

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

emax

2014-07-30 18:40

reporter   ~0002790

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

piesse

2014-08-14 08:20

reporter   ~0002814

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.

emax

2014-09-05 04:05

reporter   ~0002832

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.

psmedley

2014-09-10 19:24

administrator   ~0002834

Max, no .trp ?

emax

2014-09-10 20:28

reporter   ~0002835

not for these 2 abnormal exits
but i have them for other kinds

sent in email

thanks

massimo

Steven Levine

2015-02-03 10:30

manager   ~0003019

Is this issue resolved with the latest httpd and libc builds?

emax

2015-02-03 19:34

reporter   ~0003020

Last edited: 2015-02-03 19:34

View 2 revisions

of course no

Issue History

Date Modified Username Field Change
2014-07-25 04:34 emax New Issue
2014-07-25 09:50 Steven Levine Note Added: 0002784
2014-07-25 16:11 emax Note Added: 0002785
2014-07-26 09:26 psmedley Note Added: 0002786
2014-07-26 09:54 emax Note Added: 0002787
2014-07-26 09:54 emax Note Edited: 0002787 View Revisions
2014-07-26 10:57 Steven Levine Note Added: 0002788
2014-07-26 19:22 emax Note Added: 0002789
2014-07-26 19:33 emax Note Edited: 0002789 View Revisions
2014-07-30 18:40 emax Note Added: 0002790
2014-08-14 08:20 piesse Note Added: 0002814
2014-09-05 04:05 emax Note Added: 0002832
2014-09-10 19:24 psmedley Note Added: 0002834
2014-09-10 20:28 emax Note Added: 0002835
2015-02-03 10:30 Steven Levine Note Added: 0003019
2015-02-03 10:30 Steven Levine Assigned To => Steven Levine
2015-02-03 10:30 Steven Levine Status new => feedback
2015-02-03 19:34 emax Note Added: 0003020
2015-02-03 19:34 emax Status feedback => assigned
2015-02-03 19:34 emax Note Edited: 0003020 View Revisions