No, i trying to compile my own C application which should use MySQL C API. MySQL was installed from official package.

Implementing compiler optimizations is a black art, & frequently exhibits brittle behaviour irregardless of the platform or compiler used. Without seeing the code and makefile used, conjecture is about all anyone can provide.

My advice is to avoid optimizations altogether. There is nothing preventing compiler vendors from changing their internals in subsequent releases which will cause optimizations to break later even if you resolve this particular situation.

Well the error message suggests that a pointer is being free()'d that points to a wrong page, my guess is either you or the MySQL-Heads have screwed up a pointer.

When a pointer goes through free() it probably will still point to whatever it pointed to before and the page gets marked so it can be tucked away for re-allocation, or whatever the memory manager decides to do.

allocated memory is never 'just' the size you asked for because the memory manager needs to know how to work with it.

My guess is the memory manager is being told to free() memory that has been free()'d, and already merged with another segment of memory which you no longer have direct (safe) access to. Which may have been re-allocated in which case, one could be trying to free the wrong memory, which would probably be bad.

general disclaimer:

for as much as I love C, I'm probably not a good C programmer, so take my words with a grain of salt unless a good C programmer speakers up to related effect.

TerryP, the OP indicates that the code compiles & executes as expected without specifying -O, but when compiler optimizations are used, execution is going into the weeds as described.

Compiler optimizations incorporate very aggressive algorithms which attempt to reduce code size & execution time of the resulting binary. Techniques such as peephole optimization attempts to substitute more efficient instructions for patterns detected in the machine code generated. Unfortunately, such algorithms can lose context which may result in errant substitutions being made. The segmentation fault mentioned by the OP can be due to an incorrect table entry being referenced, be it a one-off addressing issue or the fact that a table is now being flushed earlier than what was used without optimizations being turned on. Without code, all we can do is guess.

It should be mentioned that some less aggressive optimization techniques are already incorporated into most compilers even when optimizations are not specified. These more conservative methods have been vetted for a long time & are deemed "safe". Harsher algorithms can be specified, but with them comes greater assumptions & more instability. Compiler vendors make them available as knobs to adjust, but they are available as additional switches for a reason.

I am really shamed to say now that the problem was caused by "error in programmer" i've made... That happens so often, especially after 20 hours of continuous coding. Due to stupid typo in mysql structure declaration.
I used