Reason: inconsistent compilation, federatedx is compiled without SAFEMALLOC
flag, while anything else is compiled with SAFEMALLOC.
As a consequence, my_hash_init used inside federatedx initialization does not
provide correct caller info parameters (file, line) , so they are initialized with
whatever is on stack. When info about allocated memory is output in
COM_DEBUG command, the server crashes trying to output string starting at
0xcccccccccccccccc.
The fix is to remove SAFEMALLOC preprocessor flags
from every CMakeLists.txt, except the top-level one.
Also, SAFEMALLOC is not defined by default now, instead
there is WITH_DEBUG_FULL CMake option which adds
-DSAFEMALLOC to C and C++ flags in debug compilation.
This option is off by default, because
1) Debug C runtime already has heap debugging builtin with
overwrite and leak detection
2)safemalloc considerably slows down the tests.
Note also that
- SAFEMALLOC is gone in MySQL5.5
- On Windows, heap related overflows can also be found using free pageheap utility
(that is also part of application verifier). This is even more efficient if there are no other layers
on top of Windows heap allocator, e.g it is most efficient with release version.
- Fixed problem with oqgraph and 'make dist'
Note that after this merge we have a problem show in join_outer where we examine too many rows in one specific case (related to BUG#57024).
This will be fixed when mwl#128 is merged into 5.3.
A crash may happenin the cases when the range optimizer tried to OR
two index merge such that the second one contained less range trees
than the first one.
The bug was introduced by the patch of MWL#24:
"index_merge: fair choice between index_merge union and range access".
If a primary key was used in the index intersection for
an InnoDB database the size of the memory allocated
for the best index intersection plan was one element less
than it was needed. That could cause a memory overwrite
and a crash as a result of it.
- Moved end_pagecache() to after maria_close()
- Flush page cache before closing files (in maria_pack)
Fixed test suite failure for PBXT
mysql-test/suite/pbxt/r/select.result:
We mask out the 'rows' column because it may differ from run to run
mysql-test/suite/pbxt/t/select.test:
We mask out the 'rows' column because it may differ from run to run
storage/maria/maria_chk.c:
Moved end_pagecache() to after maria_close() to not trigger end-consistency testing of pagecache.
storage/maria/maria_pack.c:
Moved end_pagecache() to after maria_close() to not trigger end-consistency testing of pagecache.
flush page cache before closing files.
A crash may happenin the cases when the range optimizer tried to OR
two index merge such that the second one contained less range trees
than the first one.
The bug was introduced by the patch of MWL#24:
"index_merge: fair choice between index_merge union and range access".
independent execution plans.
Fixed a bug in Unique::unique_add that caused a crash for a query from
index_intersect_innodb on some platforms.
Fixed two bugs in opt_range.cc that led to the choice of not the
cheapest plans for index intersections.
Fixed timing test failures.
Fixed a failure in the Aria engines page cache and log handler (found with maria.maria-big test)
- This could cause a core dump when deleting big blobs.
- Added test to end_pagecache() to verify that page cache was correctly used.
- inc_counter_for_resize_op and dec_counter_for_resize_op are called same number of times.
- All page cache blocks was properly deallocated (empty)
mysql-test/suite/innodb/t/innodb_bug38231.test:
Fixed timing issue (code comment says it all)
mysql-test/suite/innodb_plugin/t/innodb_bug38231.test:
Fixed timing issue (code comment says it all)
sql/debug_sync.cc:
Fixed compiler warning
storage/maria/ma_loghandler.c:
Fixed bug found by maria.maria-big test:
- Fixed race condition between update thread logging a very big blog and checkpoint thread.
storage/maria/ma_pagecache.c:
Added assert to ensure mutex was properly locked.
Added test to end_pagecache() to verify that page cache was correctly used.
- inc_counter_for_resize_op and dec_counter_for_resize_op are called same number of times.
- All page cache blocks was properly deallocated (empty)
In pagecache_delete_internal(), properly reset counters and pins if functions aborts.
Added missing inc_counter_for_resize_op() to pagecache_wait_lock().
Added missing dec_counter_for_resize_op() to pagecache_delete()
- Make sure creation of t1 is replicated before trying to create trigger on it on slave
- Use safe #ifdef for declaration as for definition to avoid warning about unused static function.
MTR_VS_CONFIG is now determined by looking at parent directory
of sql\*\mysqld.exe, instead of looking at *\*\BuildLog.htm
Reason : VS2010 does not create BuildLog.htm, hence prior method did not work.
- Remove all mentioning of /MAP /MAPINFO link options (does not work in VS2010).
Remove map files from packaging.
- Fix warning about ETIMEDOUT being redefined.
- Fix warning about FSP_EXTENT_SIZE in xtradb (32/64 bit right shift mismatch)
- Silence warnings coming from generated code (flex/bison) in xtradb/innodb_plugin.
- Be nice to people without cygwin (me) and add win/configure-mariadb.bat with options suitable for quick compilation, e.g no embedded
mysql-test/suite/innodb_plugin/t/innodb_bug38231.test:
Sometimes you get a timeout here; Disable the not fatal error message.
storage/xtradb/sync/sync0rw.c:
Disable compiler warning
An INSERT query log event is preceeded by an INSERT_ID intvar event if the
INSERT allocates a new auto_increment value. But if we ignore the INSERT
due to --replicate-ignore-table or similar, then the INSERT_ID event is
still executed, and the set value of INSERT_ID lingers around in the
slave sql thread THD object indefinitely until the next INSERT that
happens to need allocation of a new auto_increment value.
Normally this does not cause problems as such following INSERT would
normally come with its own INSERT_ID event. In this bug, the user had
a trigger on the slave which was missing on the master, and this
trigger had an INSERT which could be affected. In any case, it seems
better to not leave a stray INSERT_ID hanging around in the sql thread
THD indefinitely.
Note that events can also be skipped from apply_event_and_update_pos();
however it is not possible in that code to skip the INSERT without also
skipping the INSERT_ID event.
