MySql service stop by itself

Discussion of open issues, suggestions and bugs regarding MyDAC (Data Access Components for MySQL) for Delphi, C++Builder, Lazarus (and FPC)
Post Reply
777Yves
Posts: 37
Joined: Mon 09 Aug 2010 19:55
Location: Québec

MySql service stop by itself

Post by 777Yves » Tue 08 Mar 2011 14:37

Hi, is there a condition that anyone know about that could make MySql v5.5.6-rc service stop by itself ?
I don't think that this is related to MyDac but the service stop randomly when I run any Delphi XE application.

It happen also in the VCL.
In the VCL MyQuery, Sql string, write Select * from Gestions :
Click on Execute or edit

Error : Lost connection to MySql server during query
Socket error on write. WSAGetLastError return 10054($2746).

Gestions has 5 fields and 15 records.

If I check in Task manager, the service MySql is stop.
I restart it, get back in VCL double click MyQuery, click edit, everything is ok now.

This could happen on any table I have in different schema.

Any idea welcome.

Thanks, Yves. :idea:

AndreyZ

Post by AndreyZ » Wed 09 Mar 2011 15:44

Hello,

You can look what MySQL server wrote to the log file before it crashed. The name of the log file is "your_computer_name.err", and you can find it in the "%SystemDrive%\Documents and Settings\All Users\Application Data\MySQL\MySQL Server 5.5\data" directory.

777Yves
Posts: 37
Joined: Mon 09 Aug 2010 19:55
Location: Québec

MySql service stop by itself

Post by 777Yves » Wed 09 Mar 2011 16:37

Hi, this is what I found in that file, a very long story.
I hope that this will tell you something...
I send you only a few crash. The first section seems to be the beginning of crashes.
The second section is from a few crash before the last crash.

Code: Select all

110215  8:45:17 [Note] Event Scheduler: Purging the queue. 0 events
110215  8:45:19  InnoDB: Starting shutdown...
110215  8:45:29  InnoDB: Shutdown completed; log sequence number 441626093
110215  8:45:30 [Note] C:\Program Files (x86)\MySQL\MySQL Server 5.5\bin\mysqld: Shutdown complete

110215  8:54:52 [Note] Plugin 'FEDERATED' is disabled.
InnoDB: The InnoDB memory heap is disabled
InnoDB: Mutexes and rw_locks use Windows interlocked functions
InnoDB: Compressed tables use zlib 1.2.3
110215  8:54:52  InnoDB: highest supported file format is Barracuda.
110215  8:55:01 InnoDB 1.1.2 started; log sequence number 441626093
110215  8:55:01 [Note] Event Scheduler: Loaded 0 events
110215  8:55:01 [Note] C:\Program Files (x86)\MySQL\MySQL Server 5.5\bin\mysqld: ready for connections.
Version: '5.5.6-rc'  socket: ''  port: 3306  MySQL Community Server (GPL)
110215 21:44:47 [Note] Plugin 'FEDERATED' is disabled.
InnoDB: The InnoDB memory heap is disabled
InnoDB: Mutexes and rw_locks use Windows interlocked functions
InnoDB: Compressed tables use zlib 1.2.3
110215 21:44:47  InnoDB: highest supported file format is Barracuda.
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
110215 21:44:47  InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
110215 21:45:48 InnoDB 1.1.2 started; log sequence number 441628306
110215 21:45:49 [Note] Event Scheduler: Loaded 0 events
110215 21:45:49 [Note] C:\Program Files (x86)\MySQL\MySQL Server 5.5\bin\mysqld: ready for connections.
Version: '5.5.6-rc'  socket: ''  port: 3306  MySQL Community Server (GPL)
110215 21:54:58 [Note] C:\Program Files (x86)\MySQL\MySQL Server 5.5\bin\mysqld: Normal shutdown

110215 21:54:58 [Note] Event Scheduler: Purging the queue. 0 events
110215 21:54:58  InnoDB: Starting shutdown...
110215 21:55:00  InnoDB: Shutdown completed; log sequence number 441628345
110215 21:55:00 [Note] C:\Program Files (x86)\MySQL\MySQL Server 5.5\bin\mysqld: Shutdown complete

110216  6:59:00 [Note] Plugin 'FEDERATED' is disabled.
InnoDB: The InnoDB memory heap is disabled
InnoDB: Mutexes and rw_locks use Windows interlocked functions
InnoDB: Compressed tables use zlib 1.2.3
110216  6:59:01  InnoDB: highest supported file format is Barracuda.
110216  6:59:11 InnoDB 1.1.2 started; log sequence number 441628345
110216  6:59:19 [Note] Event Scheduler: Loaded 0 events
110216  6:59:19 [Note] C:\Program Files (x86)\MySQL\MySQL Server 5.5\bin\mysqld: ready for connections.
Version: '5.5.6-rc'  socket: ''  port: 3306  MySQL Community Server (GPL)
InnoDB: Error: trying to free a corrupt fetch buffer.
InnoDB: Apparent memory corruption: mem dump  len 500; hex 000000000000020000000000000000000000000000000000000020000000e40300000400000000000000b057 e50000000000000000000000000000000000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 00000035433b361b14310080a3b70170be2b063742323c74143108d8c3e20e405c26060b000000c0d0e0f096 4af82e00000088b307952d773073656c2e6300780c00000100000090db2a0690db2a06000000000000000070 0000007000000000000000700000004000000000000000000000001bc30537f805000000100047006500730 074003200300030003408003200300030003408003200300030003500200537674af82e69000088b307952d 773073656c2e6300780c00000100000008dc2a0608dc2a0600000000000000007000000070000000000000 00700000004000000000000000000000001bc30537f8060000001000470065007300740032003000300035 08003200300030003508003200300030003600200537684af82e20000088b307952d773073656c2e630078 0c00000100000080dc2a0680dc2a0600000000000000007000000070000000000000007000000040000000 00000000000000001bc30537f8070000001000470065; asc                                            W                                                                                          5C;6  1     p + 7B2<t 1     @\&          J .       -w0sel.c x         *   *         p   p       p   @              7       G e s t 2 0 0 4  2 0 0 4  2 0 0 5   7gJ .i      -w0sel.c x         *   *          p   p       p   @              7       G e s t 2 0 0 5  2 0 0 5  2 0 0 6   7hJ .       -w0sel.c x         *   *         p   p       p   @              7       G e;
InnoDB: Scanning backward trying to find previous allocated mem blocks
Mem block at - 68, file w0sel.c, line 3192
Mem block at - 980, file t0mem.c, line 69
Freed mem block at - 38316, file 0pcur.c, line 46
Mem block at - 96020, file t0mem.c, line 261
Mem block at - 96428, file t0mem.c, line 261
Mem block at - 96836, file t0mem.c, line 261
Mem block at - 97244, file t0mem.c, line 261
Mem block at - 97652, file t0mem.c, line 261
Mem block at - 98468, file t0mem.c, line 261
Mem block at - 98876, file t0mem.c, line 261
InnoDB: Scanning forward trying to find next allocated mem blocks
Mem block at + 52, file w0sel.c, line 3192
Mem block at + 172, file w0sel.c, line 3192
Mem block at + 292, file w0sel.c, line 3192
Mem block at + 412, file w0sel.c, line 3192
Mem block at + 532, file w0sel.c, line 3192
Mem block at + 652, file w0sel.c, line 3192  


Mem block at + 772, file w0sel.c, line 3192
Freed mem block at + 1436, file w0sel.c, line 3192
Freed mem block at + 6076, file mysql.c, line 670
Mem block at + 52860, file t0mem.c, line 69
110221 15:07:22  InnoDB: Assertion failure in thread 2956 in file ..\..\..\mysql-5.5.6-rc\storage\innobase\row\row0mysql.c line 791
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-recovery.html


InnoDB: about forcing recovery.
110221 15:07:22 - mysqld got exception 0xc0000005 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against 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=54525952
read_buffer_size=65536
max_used_connections=7
max_threads=100
thread_count=3
connection_count=3
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 85958 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd: 0x0
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...
InnoDB: Thread 2972 stopped in file ..\..\..\mysql-5.5.6-rc\storage\innobase\os\os0sync.c line 407
InnoDB: Thread 2976 stopped in file ..\..\..\mysql-5.5.6-rc\storage\innobase\os\os0sync.c line 624
00F69716    mysqld.exe!row_prebuilt_free()[row0mysql.c:791]
00F33357    mysqld.exe!ha_innobase::close()[ha_innodb.cc:3892]
00E51CBD    mysqld.exe!closefrm()[table.cc:2075]
00DCA1B8    mysqld.exe!intern_close_table()[sql_base.cc:853]
00DCB43D    mysqld.exe!free_cache_entry()[sql_base.cc:877]
00DCE378    mysqld.exe!tdc_flush_unused_tables()[sql_base.cc:8619]
00DAFD12    mysqld.exe!handle_manager()[sql_manager.cc:112]
01010214    mysqld.exe!pthread_start()[my_winthread.c:61]
01086C53    mysqld.exe!_callthreadstartex()[threadex.c:348]
01086CFB    mysqld.exe!_threadstartex()[threadex.c:326]
76E33677    kernel32.dll!BaseThreadInitThunk()
77B49F02    ntdll.dll!RtlInitializeExceptionChain()
77B49ED5    ntdll.dll!RtlInitializeExceptionChain()
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
110222  7:28:59 [Note] Plugin 'FEDERATED' is disabled.
InnoDB: The InnoDB memory heap is disabled
InnoDB: Mutexes and rw_locks use Windows interlocked functions
InnoDB: Compressed tables use zlib 1.2.3
110222  7:28:59  InnoDB: highest supported file format is Barracuda.
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
110222  7:28:59  InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
110222  7:29:35 InnoDB 1.1.2 started; log sequence number 441734774
110222  7:29:40 [Note] Event Scheduler: Loaded 0 events
110222  7:29:40 [Note] C:\Program Files (x86)\MySQL\MySQL Server 5.5\bin\mysqld: ready for connections.
Version: '5.5.6-rc'  socket: ''  port: 3306  MySQL Community Server (GPL)
110222  8:58:27 [Note] C:\Program Files (x86)\MySQL\MySQL Server 5.5\bin\mysqld: Normal shutdown

110222  8:58:27 [Note] Event Scheduler: Purging the queue. 0 events
110222  8:58:27  InnoDB: Starting shutdown...
110222  8:58:31  InnoDB: Shutdown completed; log sequence number 441735068
110222  8:58:31 [Note] C:\Program Files (x86)\MySQL\MySQL Server 5.5\bin\mysqld: Shutdown complete

110222  9:01:46 [Note] Plugin 'FEDERATED' is disabled.
InnoDB: The InnoDB memory heap is disabled
InnoDB: Mutexes and rw_locks use Windows interlocked functions
InnoDB: Compressed tables use zlib 1.2.3
110222  9:01:46  InnoDB: highest supported file format is Barracuda.
110222  9:01:59 InnoDB 1.1.2 started; log sequence number 441735068
110222  9:01:59 [Note] Event Scheduler: Loaded 0 events
110222  9:01:59 [Note] C:\Program Files (x86)\MySQL\MySQL Server 5.5\bin\mysqld: ready for connections.
Version: '5.5.6-rc'  socket: ''  port: 3306  MySQL Community Server (GPL)
InnoDB: Error: trying to free a corrupt fetch buffer.
InnoDB: Apparent memory corruption: mem dump  len 500; hex ffffe87901062f000000947a01061b000000447a010603000000787a0106ffffffffe479 010625000000807a01062d000000507a0106ffffffff547a0106200000007c7a01061d 0000006c7a0106ffffffffe079010629000000887a010619000000287a0106ffffffffa07a 010627000000607a01060f0 00000487a0106ffffffff8c7a0106ffffffff247a01063100000 09c7a0106fffffffff4790106f fffffff907a01061a000000407a0106acdeb60b69473408b307952d773073656c2e63007 80c0000010000008802fd058802fd05000000000000000070000000700000000000000 
0700000004000000000 000000000000001bc30537f805000000100047006500730074 00320030003000340800 3200300030003408003200300030003500200537a3cebe1c5e473408705af605d8a11a 020f000000c0d0e0f0 2bab3a1720200080cc08fc0500000000200afd056042fd0500000000ec8afc0500000 00000000000609afc05109cfc0500000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000008e8aa010000000000000000000000 00609afc0500000000009afc0506000000c0ffffff009afc0500000000049afc05060000 00c0ffffff049a; asc    y  /    z      Dz      xz       y  %    z  -   Pz      Tz      |z      lz       y  )    z      (z       z  '   `z      Hz       z      $z  1    z       y       z      @z      iG4    -w0sel.c x                       p   p       p   @              7        G e s t 2 0 0 4  2 0 0 4  2 0 0 5   7    ^G4 pZ              + :                 `B                  `                                                                                                   `                                         ;
InnoDB: Scanning backward trying to find previous allocated mem blocks
Mem block at - 68, file w0sel.c, line 3192
Mem block at - 35196, file w0sel.c, line 3192
Mem block at - 35596, file mysql.c, line 670
Mem block at - 39756, file x0trx.c, line 189
Mem block at - 320204, file w0sel.c, line 3192
Mem block at - 397076, file t0mem.c, line 69
Mem block at - 438908, file t0mem.c, line 69
Mem block at - 439780, file t0mem.c, line 69
Mem block at - 441828, file t0mem.c, line 261
Mem block at - 442644, file t0mem.c, line 69
InnoDB: Scanning forward trying to find next allocated mem blocks
Mem block at + 41156, file x0trx.c, line 99
Mem block at + 42052, file x0trx.c, line 177
Mem block at + 42380, file w0sel.c, line 3192
Mem block at + 100436, file x0trx.c, line 165
Mem block at + 285180, file w0sel.c, line 3192
Mem block at + 348932, file w0sel.c, line 3192
Mem block at + 349052, file w0sel.c, line 3192
110222  9:31:59 - mysqld got exception 0xc0000005 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against 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=54525952
read_buffer_size=65536
max_used_connections=2
max_threads=100
thread_count=2
connection_count=2
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 85958 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Code: Select all

thd: 0x0
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...
0159E3D5    mysqld.exe!mem_analyze_corruption()[mem0dbg.c:839]
015996FD    mysqld.exe!row_prebuilt_free()[row0mysql.c:791]
01563357    mysqld.exe!ha_innobase::close()[ha_innodb.cc:3892]
01481CBD    mysqld.exe!closefrm()[table.cc:2075]
013FA1B8    mysqld.exe!intern_close_table()[sql_base.cc:853]
013FB43D    mysqld.exe!free_cache_entry()[sql_base.cc:877]
013FE378    mysqld.exe!tdc_flush_unused_tables()[sql_base.cc:8619]
013DFD12    mysqld.exe!handle_manager()[sql_manager.cc:112]
01640214    mysqld.exe!pthread_start()[my_winthread.c:61]
016B6C53    mysqld.exe!_callthreadstartex()[threadex.c:348]
016B6CFB    mysqld.exe!_threadstartex()[threadex.c:326]
76F53677    kernel32.dll!BaseThreadInitThunk()
77929F02    ntdll.dll!RtlInitializeExceptionChain()
77929ED5    ntdll.dll!RtlInitializeExceptionChain()
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
110307 11:59:53 [Note] Plugin 'FEDERATED' is disabled.
InnoDB: The InnoDB memory heap is disabled
InnoDB: Mutexes and rw_locks use Windows interlocked functions
InnoDB: Compressed tables use zlib 1.2.3
110307 11:59:53  InnoDB: highest supported file format is Barracuda.
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
110307 11:59:53  InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
110307 11:59:54 InnoDB 1.1.2 started; log sequence number 441775169
110307 11:59:54 [Note] Event Scheduler: Loaded 0 events
110307 11:59:54 [Note] C:\Program Files (x86)\MySQL\MySQL Server 5.5\bin\mysqld: ready for connections.
Version: '5.5.6-rc'  socket: ''  port: 3306  MySQL Community Server (GPL)
110307 14:11:02 [Note] C:\Program Files (x86)\MySQL\MySQL Server 5.5\bin\mysqld: Normal shutdown

110307 14:11:02 [Note] Event Scheduler: Purging the queue. 0 events
110307 14:11:02  InnoDB: Starting shutdown...
110307 14:11:05  InnoDB: Shutdown completed; log sequence number 441775169
110307 14:11:05 [Note] C:\Program Files (x86)\MySQL\MySQL Server 5.5\bin\mysqld: Shutdown complete

110307 14:11:11 [Note] Plugin 'FEDERATED' is disabled.
InnoDB: The InnoDB memory heap is disabled
InnoDB: Mutexes and rw_locks use Windows interlocked functions
InnoDB: Compressed tables use zlib 1.2.3
110307 14:11:11  InnoDB: highest supported file format is Barracuda.
110307 14:11:12 InnoDB 1.1.2 started; log sequence number 441775169
110307 14:11:12 [Note] Event Scheduler: Loaded 0 events
110307 14:11:12 [Note] C:\Program Files (x86)\MySQL\MySQL Server 5.5\bin\mysqld: ready for connections.
Version: '5.5.6-rc'  socket: ''  port: 3306  MySQL Community Server (GPL)
InnoDB: Error: trying to free a corrupt fetch buffer.
InnoDB: Apparent memory corruption: mem dump  len 500; hex 00000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000 003000300 035002005370100000001000 000f5d97b48f729340080fa070630d00606000000000100000001000000fffffffffffff fff020000000000000000000000ac1d0806ac1d0806000000000000000000000000 00
110309  9:07:11 InnoDB 1.1.2 started; log sequence number 441775948
110309  9:07:11 [Note] Event Scheduler: Loaded 0 events
110309  9:07:11 [Note] C:\Program Files (x86)\MySQL\MySQL Server 5.5\bin\mysqld: ready for connections.
Version: '5.5.6-rc'  socket: ''  port: 3306  MySQL Community Server (GPL)

AndreyZ

Post by AndreyZ » Thu 10 Mar 2011 13:51

Please try opening tables of your database and executing queries to it using dbForge Studio for MySQL. You can download dbForge Studio for MySQL here: http://www.devart.com/dbforge/mysql/stu ... nload.html
Also you can check your database in dbForge Studio for MySQL. For this you should perform the following steps in it:
- create connection to your server using Database Explorer;
- in Database Explorer right click on your database and choose "Table Maintenance" from the popup menu.
Using Table Maintenance Wizard you can perform checking and repairing operations with you database. For more information about this wizard, please read the "Table Maintenance Wizard" topic of the dbForge Studio for MySQL documentation.

777Yves
Posts: 37
Joined: Mon 09 Aug 2010 19:55
Location: Québec

MySql service stop by itself

Post by 777Yves » Mon 14 Mar 2011 14:20

Hi,
I have download dbForge Studio and perform a check on the 4 schema I have and all tables are Ok.

Yves

AndreyZ

Post by AndreyZ » Tue 15 Mar 2011 12:24

Did you execute your queries in dbForge Studio for MySQL? Did the server crash during query execution?

777Yves
Posts: 37
Joined: Mon 09 Aug 2010 19:55
Location: Québec

MySql service stop by itself

Post by 777Yves » Tue 15 Mar 2011 14:46

Hi, yes I try in dbForge and I had no crash but I have experience no crash in Delphi either since I found and modify the fields in the fields editor.

I think the point is that I am moving from Delphi 5 to Delphi XE and from DBF to MySQL.
For some reason, in query or table, the field list is wrong and even if I delete all the fields in the field list and recreate it, it still wrong. But if I recreate the fields list while the table is open, bingo, it is updated like it should and the crash are gone away. :o :D

I really hope that this was the real problem.

Thanks

Yves

AndreyZ

Post by AndreyZ » Wed 16 Mar 2011 10:11

We are interested in investigating this problem. Please try composing a small sample to demonstrate the problem and send it to andreyz*devart*com, including a script to create and fill a table.

777Yves
Posts: 37
Joined: Mon 09 Aug 2010 19:55
Location: Québec

MySql service stop by itself

Post by 777Yves » Wed 16 Mar 2011 13:15

Hi Andrey,
I have to ask you a question.
Is there a possibility, that when we are in Delphi XE, and in an application, there is a MyConnection and a MyQuery that are active in the IDE and I then exit or run F9 the application, at this exact point is there a possible confusion for the server for those connections. I ask you that because this is always at this point that the server stop.


About investigating the fields in the field editor.
I don't see any way to make an application that replicate this problem.
- First take a Delphi 5 application that access DBF via the BDE
- Use a powerful text editor to replace directly in the source code :
- replace tQuery by MyQuery
- repalce tTable by MyTable
- remove all property lines that are not supported
- then try to compile in XE
all fields in the fields editor are still there and this is the condition I have enconter. Most table were ok but for some table with Int(x) field there was problems. And how I have fix that is what I already explain.

AndreyZ

Post by AndreyZ » Thu 17 Mar 2011 14:38

When you start your application that has active TMyConnection components, all these components are trying to establish a connection to the server. When you close your application, all active TMyConnection components perform disconnecting from the server. It's possible that in these situations you can have some connecting problems, but we didn't encounter such problems as MySQL crashing in the past.
I have tried to reproduce this problem in a way you offered, but with no success. We will be able to investigate this problem only if we have a project that demonstrates it. Please try composing this project and send it to me.

Post Reply