| Bug #71333 | happlier crashes if it exits before seeing a table index event | ||
|---|---|---|---|
| Submitted: | 9 Jan 2014 16:28 | Modified: | 21 Mar 2014 21:51 |
| Reporter: | Michael Albert | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Utilities: Binlog Events | Severity: | S3 (Non-critical) |
| Version: | 0.1.0 | OS: | Any |
| Assigned to: | CPU Architecture: | Any | |
| Tags: | happlier, repliation, Table_index | ||
[16 Jan 2014 10:19]
Mats Kindahl
Hi Michael, Thank you for the bug report, it is verified as you describe.
[21 Mar 2014 21:51]
Paul DuBois
Fixed in 0.2.0. Bug fix for unreleased product. No changelog entry needed.
Description: The code for Table_index::~Table_index will crash the program if the d'tor is called while the table is empty. The current code is show below. This probably should be a "for" loop, so that if the index is empty there is no attempt to deference the iterator. Table_index::~Table_index () { for (Int2event_map::iterator it= begin(); it != end(); ++it) { delete it->second; } } How to repeat: I found this incidental to another problem. Due to an unrelated misconfiguration, I managed to get the loop to exit before any table index entries were created. However, the program would then report a segmentation fault due the the d'tor de-referencing the end() iterator. This obscured the actual problem. Admittedly, this is a corner case, but presumably the program will eventually need to exit cleanly even if no data has arrived. Thanks. Suggested fix: Please make the "do" loop in Table_index::~Table_index() into a "for" loop so that in the (unusual) case that the program is terminated before any data is transferred, the program will exit cleanly (or at least not seg-fault in this d'tor). Thanks!