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:
None 
Category:MySQL Server: Errors Severity:S2 (Serious)
Version:5.0.66a, 5.0.58-win32, mysql-5.1.24-rc-winx64 OS:Microsoft Windows (xp64)
Assigned to: Vladislav Vaintroub CPU Architecture:Any
Triage: Triaged: D3 (Medium)

[11 Apr 2008 8:48] Shane Bester
Description:
On windows, the function names are not printed correctly when crash message is output:

080411 10:40: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=8388572
read_buffer_size=131072
max_used_connections=3
max_threads=151
threads_connected=3
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 338099 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd: 0x5b09aa8
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...
0000000000754FC8    mysqld-debug.exe!???
000000000075C2B4    mysqld-debug.exe!???
0000000000756C87    mysqld-debug.exe!???
0000000000718E70    mysqld-debug.exe!???
000000000072511D    mysqld-debug.exe!???
0000000000716A18    mysqld-debug.exe!???
0000000000715E0A    mysqld-debug.exe!???
000000000086FD06    mysqld-debug.exe!???
000000000096D905    mysqld-debug.exe!???
0000000000B5DB25    mysqld-debug.exe!???
0000000000B5DAF7    mysqld-debug.exe!???
0000000077D6B69A    kernel32.dll!BaseThreadStart()
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0000000005B334B0=select 1 from `t1` where (@@sort_buffer_size)
thd->thread_id=2
thd->killed=NOT_KILLED
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.

E:\mysql-5.1.24-rc-winx64\bin>mysqld --console --skip-grant-tables --skip-name-resolve --sy
InnoDB: Log scan progressed past the checkpoint lsn 0 3883779
080411 10:41:15  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: Doing recovery: scanned up to log sequence number 0 3909942
080411 10:41:15  InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 2
InnoDB: Apply batch completed
080411 10:41:16  InnoDB: Started; log sequence number 0 3909942
080411 10:41:16 [Note] mysqld: ready for connections.
Version: '5.1.24-rc-community'  socket: ''  port: 3306  MySQL Community Server (GPL)

How to repeat:
crash server and look at error report.  to crash 5.1.24 server easily, use the testcase from bug #32124

drop table if exists `t1`;
create table `t1` (a int)engine=myisam;
prepare stmt from 'select 1 from `t1` where `a` = any (select (@@tmpdir))';
execute stmt;
deallocate prepare stmt;

Suggested fix:
we need resolved stack traces.
[11 Apr 2008 12:33] Shane Bester
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] Miguel Solorzano
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] Shane Bester
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)