I am looking for ways to track to the source of the problem. (...) but the error log (below) confuses me.
The error message simply means that glibc's stack protection routines fired due to a corruption of the (C level) stack. Unfortunately, the reasons for this happening are manifold, and detailed knowledge of the internals right down to the assembly level might be required to succesfully debug such things. It could be a buffer overflow, mismatching ABIs (binary interfaces) of the libraries involved, etc. As the last stack frame reported for mysql.so is just an address (without a name), it's likely that the stack (typically function call return address) has already been messed up before that point, which means you'd have to start looking from mysql_bind_ph...
OTOH, unless you're already familiar with tools such as gdb and valgrind (or would like to learn using them), I'd suggest you try approaching the problem at a somewhat higher level first — maybe you don't need to spend your time debugging things that someone else may already have fixed... In other words, try upgrading or reinstalling the components involved, check if compatible libs are being loaded (for example, if the MySQL shared lib (libmysql.so) that the Perl binding DBD/mysql/mysql.so loads is the one that it was originally linked against), etc.
In reply to Re: tracking "stack smashing detected"
by almut
in thread tracking "stack smashing detected"
by manoj123
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |