| Bug #57614 | 'Error 1067: The process terminated unexpectedly' when installing from sources | ||
|---|---|---|---|
| Submitted: | 21 Oct 2010 1:08 | Modified: | 22 Oct 2010 23:49 |
| Reporter: | Yuri Popoff | Email Updates: | |
| Status: | Duplicate | Impact on me: | |
| Category: | MySQL Server: Windows | Severity: | S3 (Non-critical) |
| Version: | 5.1.51 | OS: | Windows (XP) |
| Assigned to: | CPU Architecture: | Any | |
| Tags: | regression | ||
[21 Oct 2010 9:43]
MySQL Verification Team
Thank you for the bug report. Microsoft Windows [Version 6.0.6002] Copyright (c) 2006 Microsoft Corporation. All rights reserved. C:\Windows\system32>net start mysqld51 The mysqld51 service is starting... The mysqld51 service could not be started. A system error has occurred. System error 1067 has occurred. The process terminated unexpectedly.
[21 Oct 2010 9:45]
MySQL Verification Team
Starting from command line: C:\DBS>c:\dbs\5.1\bin\mysqld --console --standalone --port=3306 --ignore-builtin-innodb --plugin-load=innodb=ha_innodb_plugin.dll;innodb_trx=ha_innodb_plugin.dll;innodb_locks=ha_innodb_plugin.dll;innodb_lock_waits=ha_innodb_plugin.dll;innodb_cmp =ha_innodb_plugin.dll 101021 7:44:11 [Note] Plugin 'FEDERATED' is disabled. InnoDB: The InnoDB memory heap is disabled InnoDB: Mutexes and rw_locks use InnoDB's own implementation InnoDB: Compressed tables use zlib 1.2.3 101021 7:44:11 InnoDB: highest supported file format is Barracuda. 101021 7:44:11 InnoDB Plugin 1.0.12 started; log sequence number 44260 101021 7:44:11 [Note] Event Scheduler: Loaded 0 events 101021 7:44:11 [Note] c:\dbs\5.1\bin\mysqld: ready for connections. Version: '5.1.53-Win X64' socket: '' port: 3306 Source distribution
[21 Oct 2010 22:51]
MySQL Verification Team
Notice the empty err file:
C:\DBS>dir 5.1\data\tikal.err
Volume in drive C has no label.
Volume Serial Number is 20EC-38AD
Directory of C:\DBS\5.1\data
11/10/2010 14:26 0 tikal.err
1 File(s) 0 bytes
0 Dir(s) 468.139.085.824 bytes free
C:\DBS>
[22 Oct 2010 20:49]
Vladislav Vaintroub
This seems to be a duplicate of Bug #56821 Failure to start the MySQL Service, which is fixed about a month ago.
[22 Oct 2010 23:41]
Yuri Popoff
Yes, you are right. After applying the patch from that bug the service starts successfully. Sorry for duplicate.
Description: The 'Error 1067: The process terminated unexpectedly' error occurs when installing MySQL 5.1.51 from sources as a Windows service. Used compiler - Visual Studio Express 2008. Tried both Debug and Release configurations. The error (*.err) file is created, but is empty. When i start mysqld.exe --standalone, it starts and works correctly. If I replace an executable compiled by me with the executable from the bimary distributions (only mysqld.exe, leaving everything else unchanged), then the service starts successfully. How to repeat: 1. Download sources (MySQL Community Server -> 5.1.51 -> Generally Available -> Source Code). 2. Used configuration: configure WITH_INNOBASE_STORAGE_ENGINE 3. Compile with Visual Studio Express 2008 4. Install the server as a Windows service. Expected result: service is running. Got result: 'Error 1067: The process terminated unexpectedly', and service is not running. Suggested fix: I've traced the server and found a bad behaviour in the reopen_fstreams() function in the sql/log.cc file. It currently contains the following lines: if (outstream) { stream_fd= _fileno(outstream); if (_dup2(handle_fd, stream_fd) < 0) { CloseHandle(osfh); return TRUE; } } After compiling with VS Express-2008, I see that outstream is not NULL, but _fileno() returns -2. MSDN says this is the expected behaviour if stdout is not assosiated with a stream, for example, in a Windows application without a cosole window: http://msdn.microsoft.com/en-us/library/zs6wbdhx(v=VS.90).aspx Now, having the stream_fd equals -2, the subsequent call to _dup2() returns -1 (and sets errno=9), because -2 is an invalid handler. Having this, reopen_fstreams() returns true, and the server terminates. As a quick fix, i've tried to add an additional check: if (outstream) { stream_fd= _fileno(outstream); if(stream_fd>0) { if (_dup2(handle_fd, stream_fd) < 0) { CloseHandle(osfh); return TRUE; } } } After this the service starts normally, but this "fix" leads to all messages to disappear from the error log (no messages are logged at all after this, because streams are not reassigned to the my_user_name.err file).