MySQL C library - segmentation fault on mysql_select_db() when using CC optimisation

[gor]

Hello,

I have segmentation fault while trying to execute a binary that uses MySQL C API. An error occurs every time mysql_select_db() is called. The output says:in free(): error: free_pages: pointer to wrong page
Abort trap (core dumped)
After hours of debugging, i've discovered that -O compiler flag causes that error to come. If compiled without -O flag - everything works like a charm. e.g. (compiler options from Makefile):
COPT=-I /usr/local/include/mysql -L /usr/local/lib/mysql -O Binary crashes with segfault

COPT=-I /usr/local/include/mysql -L /usr/local/lib/mysql Binary works fine

I am not sure whether the problem is caused by MySQL C API bug or error in cc (or maybe error in programmer :) )

The OS is OpenBSD 4.2 GENERIC.MP amd64

Thank you for suggestions.
Regards.

[ocicat]

I have segmentation fault while trying to execute a binary that uses MySQL C API.
Are you compiling MySQL from ports?

[gor]

Thank you for reply.

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

[ocicat]

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.

[TerryP]

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.

[ocicat]

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.

[TerryP]

I should also mention there is no guarantee that my brain cells are actually useful ;-)

thanks.

[gor]

Hello,

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 MYSQL *db_conn; /* WRONG */
instead ofMYSQL db_conn; /* CORRECT */

Shure, i should read compiler warnings more carefully.

Thats all. Problem solved.

Thanks to everyone for replies and suggestions!

Regards.