| Bug #50496 | rpl_backup fails sporadically (looks like memory corruption) | ||
|---|---|---|---|
| Submitted: | 21 Jan 2010 8:31 | Modified: | 2 Mar 2010 2:22 |
| Reporter: | Alexander Nozdrin | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server: Backup | Severity: | S3 (Non-critical) |
| Version: | 6.0, mysql-6.0-codebase-bugfixing | OS: | Any |
| Assigned to: | Chuck Bell | CPU Architecture: | Any |
| Tags: | experimental, PB, test failure | ||
[21 Jan 2010 8:32]
Alexander Nozdrin
The test case has been marked experimental due to this bug.
[21 Jan 2010 11:14]
Sveta Smirnova
Thank you for the report. Verified as described on Solaris box
[21 Jan 2010 20:53]
Chuck Bell
Easy fix. Similar to another recent fix.
The str attribute in the LEX_CSTRING struct can be accessed like this on most 32-bit and some 64-bit systems:
LEX_SCSTRING mything.
printf("%s\n", mything);
But on some 64-bit systems (e.g. Windows, Solaris), this fails because the location of the str attribute is not 0 positions from the address of the struct itself.
The correct way to reference a LEX_CSTRING str attribute is:
printf("%s]n:, mything.str);
This patch shall correct this in the code in sql_repl.cc. This will fix the strange messages seen on some systems in pushbuild.
[21 Jan 2010 21:27]
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/97779 2936 Chuck Bell 2010-01-21 [merge] BUG#50496 : rpl_backup fails sporadically (looks like memory corruption) The test is producing output that contains garbage information. This is caused by an incorrect reference to the str attribute of the LEX_CSTRING structure. This occurs on only some systems as others are able to dereference the attribute correctly. This patch changes the reference to the str attribute by referencing it directly. @ sql/sql_repl.cc Change to reference the str attribute directly.
[22 Jan 2010 8:35]
Ingo Strüwing
Approved. No comments.
[22 Jan 2010 9:06]
Sanjay Manwani
Approved - Makes Sense.
[22 Jan 2010 16:23]
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/97906 2937 Chuck Bell 2010-01-22 [merge] Local merge before push of BUG#50496
[20 Feb 2010 9:18]
Bugs System
Pushed into 6.0.14-alpha (revid:ingo.struewing@sun.com-20100218152520-s4v1ld76bif06eqn) (version source revid:ingo.struewing@sun.com-20100122221225-ccgkfpesvrttdlc1) (merge vers: 6.0.14-alpha) (pib:16)
[2 Mar 2010 2:22]
Paul DuBois
Noted in 6.0.14 changelog. An incorrect string access caused part of an error message to be output as garbage.
Description: rpl_backup fails from time to time with the symptoms as follows: rpl.rpl_backup [ fail ] Test ended at 2010-01-20 21:50:16 CURRENT_TEST: rpl.rpl_backup 'diff' is not recognized as an internal or external command, operable program or batch file. --- H:/pb2/test/sb_2-1213167-1264011958.8/mysql-6.0.14-alpha-win-x86_64-test/mysql-test/suite/rpl/r/rpl_backup.result 2010-01-20 20:31:27.000000000 +0300 +++ H:\pb2\test\sb_2-1213167-1264011958.8\mysql-6.0.14-alpha-win-x86_64-test\mysql-test\suite\rpl\r\rpl_backup.reject 2010-01-20 23:50:15.967604800 +0300 @@ -363,7 +363,7 @@ SET DEBUG_SYNC = 'now WAIT_FOR restore_running'; # Try to start the slave while restore is running -- gets error. SLAVE START; -ERROR HY000: Cannot start slave. SLAVE START is blocked by RESTORE. +ERROR HY000: Cannot start slave. SLAVE START is blocked by (\012D?. SET DEBUG_SYNC = 'now SIGNAL proceed'; SHOW SLAVE STATUS; Slave_IO_State # mysqltest: Result content mismatch How to repeat: XRef2: http://tinyurl.com/ybqdo8b