| Bug #35987 | crash report on windows doesn't resolve stack traces? | ||
|---|---|---|---|
| Submitted: | 11 Apr 2008 8:48 | Modified: | 17 Oct 2008 17:25 |
| Reporter: | Shane Bester (Platinum Quality Contributor) | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server: Errors | Severity: | S2 (Serious) |
| Version: | 5.0.66a, 5.0.58-win32, mysql-5.1.24-rc-winx64 | OS: | Windows (xp64) |
| Assigned to: | Vladislav Vaintroub | CPU Architecture: | Any |
[11 Apr 2008 8:48]
Shane Bester
[11 Apr 2008 12:33]
MySQL Verification Team
5.0.58-win32 doesn't do proper stacks either. i'll try get more different crashes to test it: Version: '5.0.58-enterprise-gpl-nt' socket: '' port: 3306 MySQL Enterprise Server (GPL) 080411 14:30:40 - 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=8384512 read_buffer_size=131072 max_used_connections=1 max_connections=100 threads_connected=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 225787 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=04F26728 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... 0063F540 mysqld-nt.exe!??? Trying to get some variables. Some pointers may be invalid and cause the dump to abort... thd->query at 05782C20=select convert(t1.`a` using gbk) from t2,t1 group by 1 limit 1 into @nullll thd->thread_id=1 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.
[11 Apr 2008 12:38]
MySQL Verification Team
Thank you for the bug report. On XP 32-bit: c:\dbs>5.1\bin\mysqld --standalone --console InnoDB: The log sequence number in ibdata files does not match InnoDB: the log sequence number in the ib_logfiles! 080411 9:35:04 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... InnoDB: Last MySQL binlog file position 0 891, file name .\data-bin.000007 080411 9:35:05 InnoDB: Started; log sequence number 0 7401999 080411 9:35:05 [Note] Recovering after a crash using data-bin 080411 9:35:05 [Note] Starting crash recovery... 080411 9:35:05 [Note] Crash recovery finished. 080411 9:35:05 [Note] Event Scheduler: Loaded 1 event 080411 9:35:05 [Note] 5.1\bin\mysqld: ready for connections. Version: '5.1.25-rc-nt-log' socket: '' port: 3306 Source distribution runtime error R6025 - pure virtual function call c:\dbs>
[30 Jul 2008 19:05]
MySQL Verification Team
workaround: use the .map and the .pdb files to resolve the symbols
[15 Sep 2008 12:59]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/54100 2678 Vladislav Vaintroub 2008-09-15 Bug#35987 - crash report on windows doesn't resolve stack traces. The problem here is that symbols can not be loaded, because symbol path is not set and default path does not include the directory where PDB is located. The problem is _not_ reproducible on the same machine where mysqld.exe is built - if PDB is not found in the symbol path, dbghelp would fallback to fully qualified PDB path as given in the executable header and on the build host this will succeed. The solution is to calculate symbol path and pass it to SymInitialize() call.
[15 Sep 2008 15:28]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/54128 2678 Vladislav Vaintroub 2008-09-15 Bug#35987 - crash report on windows doesn't resolve stack traces. The problem here is that symbols can not be loaded, because symbol path is not set and default path does not include the directory where PDB is located. The problem is _not_ reproducible on the same machine where mysqld.exe is built - if PDB is not found in the symbol path, dbghelp would fallback to fully qualified PDB path as given in the executable header and on the build host this will succeed. The solution is to calculate symbol path and pass it to SymInitialize() call.
[16 Sep 2008 11:17]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/54195 2680 Vladislav Vaintroub 2008-09-16 Bug#35987 - post-review fix Correct usage of strncat() in get_symbol_path() 3rd parameter to strncat is changed to be count of remaining bytes in the output buffer minus 1.
[16 Sep 2008 13:44]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/54206 2680 Vladislav Vaintroub 2008-09-16 Bug#35987 - post-review fix Correct usage of strncat() in get_symbol_path() 3rd parameter to strncat is changed to be count of remaining bytes in the output buffer minus 1.
[9 Oct 2008 18:14]
Bugs System
Pushed into 5.1.30 (revid:vvaintroub@mysql.com-20080916111641-sw7q80ws3wsprwiu) (version source revid:v.narayanan@sun.com-20080916142044-vz0qug6c4jmzs98s) (pib:4)
[15 Oct 2008 15:04]
Paul DuBois
This is actually pushed to 5.1.29, not 5.1.30.
[15 Oct 2008 17:14]
Paul DuBois
Noted in 5.1.29 changelog. For crash reports on Windows, symbol names in stack traces were not correctly resolved. Setting report to NDI pending push into 6.0.x.
[17 Oct 2008 16:43]
Bugs System
Pushed into 6.0.8-alpha (revid:vvaintroub@mysql.com-20080916111641-sw7q80ws3wsprwiu) (version source revid:vvaintroub@mysql.com-20080916132607-mdp0g0rmtezlc4jj) (pib:5)
[17 Oct 2008 17:25]
Paul DuBois
Noted in 6.0.8 changelog.
[28 Oct 2008 21:03]
Bugs System
Pushed into 5.1.29-ndb-6.2.17 (revid:vvaintroub@mysql.com-20080916111641-sw7q80ws3wsprwiu) (version source revid:tomas.ulin@sun.com-20081028140209-u4emkk1xphi5tkfb) (pib:5)
[28 Oct 2008 22:22]
Bugs System
Pushed into 5.1.29-ndb-6.3.19 (revid:vvaintroub@mysql.com-20080916111641-sw7q80ws3wsprwiu) (version source revid:tomas.ulin@sun.com-20081028194045-0353yg8cvd2c7dd1) (pib:5)
[1 Nov 2008 9:47]
Bugs System
Pushed into 5.1.29-ndb-6.4.0 (revid:vvaintroub@mysql.com-20080916111641-sw7q80ws3wsprwiu) (version source revid:jonas@mysql.com-20081101082305-qx5a1bj0z7i8ueys) (pib:5)
