I have a c program that maintains a persistent MySQL connection, version 5.1.46. If I restart mysql while the program is running I get a double free or corruption error as such:
# /etc/init.d/mysql restart
Shutting down MySQL........ [ OK ]
Starting MySQL.*** glibc detected *** /home/user/a.out: double free or corruption (!prev): 0x000000000b64dd00 ***
======= Backtrace: =========
/lib64/libc.so.6[0x3739471634]
I am expecting the connection to automatically reconnect since I have set the MYSQL_OPT_RECONNECT option and have not explicitly closed this connection yet. In addition, the query I am executing is not a char* that I have accidentally set to NULL or deallocated, it is a constant, double quoted string.
Here are a few lines from the resulting core file in gdb
#11 0x000000000044ed71 in mysql_send_query (mysql=0x41966aa0, query=0x41966100 "SELECT count (*) from TableA", length=27) at client.c:2894
#12 0x000000000044edd9 in mysql_real_query (mysql=0x602a, query=0x602d <Address 0x602d out of bounds>, length=6) at client.c:2905
#13 0x000000000042b42f in do_query (conn=0x41966aa0, msg=0x41966100 "SELECT count(*) from TableA") at dosql.cpp:20
Any ideas why this might be occurring?
Any ideas why this might be occurring?
Because of a bug in MySQL.
You can try to update to later package, and see if the problem disappears.
Alternatively, run your client program under Valgrind, and it will report the bug in a way that is usable for fixing it. In particular, it will report
stack trace where the memory was allocated
stack trace where it has been freed
stack trace where double-free is happening (should be same as your GDB stack trace)
Given that info, you could report the bug to MySQL developers, and hope it will eventually be fixed.
Related
I compiled the sourceforge tcl executable, it passes all the tests supplied, and it runs with the same segfault I see in my downloaded executable, 8.6.9. I'm running on Ubuntu 16.04 (for legacy reasons) on an AMD processor. ( I have run on ubuntu 18.04 on my laptop, it has the same failure. )
So, next I recompiled with "--enable-symbols=mem" turned on to see if a memory leak is causing the segfault, and now it fails immediately with:
Trying to decr ref count of Tcl_Obj allocated in another thread
./runMeg.sh: line 3: 29972 Aborted (core dumped) ../source/main_megatron.
I'm not seeing any answer on what to do with this response, can someone advise on what this means I need to fix?
All my threads are of the form:
set graphDisplayThread [ thread::create {
after [expr {int(1000) }]
.....
puts "...Initialized graphDisplayUpdate_02 ID $c update."
thread::wait
}]
and:
thread::send $::graphDisplayThread {
incr b
graphDisplayUpdate .c
}
All shared variables are referenced AFTER mutex is captured, and through TSV variables. There are 5 threads in the application, which has no C-code in it at all. Around 2000 lines of code, in total.
The app runs thousands of cycles and then segfaults at random points with a prior ActiveState 8.6.9 pre-compiled version. So, now I'm trying to isolate the failure point with compiled SourceForge 8.6.9 memory checks as a first step, but the issue above is the first one I encounter - and it occurs immediately after starting.
Update (5/16/19 8:28 EST): New Detail to answer comments below.... This application has no C-code in it, and the Tcl_Obj error ONLY appears in the sourceForge-based, 8.6.9 compiles (2) I did myself, not the ActiveState 8.6.9 pre-built download. And the error in the sourceForge code occurs in both the twin "MEM_DEBUG" and NO-"MEM_DEBUG" builds I made in tandem and tested. Both passed all install tests.
To summarize:
sourceForge 8.6.9 compile w/MEM_DEBUG option: Tcl_Obj Abort error
sourceForge 8.6.9 compile w/o MEM_DEBUG option: Tcl_Obj Abort error
ActiveState 8.6.9 build: does not Abort, random seg fault
Why should I trust the sourceForge build I made myself, more than the ActiveState pre-built executable which does not exhibit the problem? And if we do trust the sourceForge compiled version, how do I isolate where the TclObject error is created by the offending TCL code?
Update 5/16/19#13:34EST: The same segfault appears with ActiveState 8.6.9 on Ubuntu 18.04. Haven't checked my builds of SourceForge yet to see how they behave.
By methodically hacking out code blocks and watching to see if the Tcl_Obj error dissappeared or not, I found 2 errors:
I had re-declared my mutex and cond variables more than once. Now it is declared once and referenced in all other places.
A code remnant removing a TSV was found in a place I no longer wanted it.
This also fixed the segfault.
Thanks for all the help and hints, mrcalvin.
I have a weird behaviour on my application using QSqlDatabase.
This is the simple code i'm using:
QSqlDatabase db = QSqlDatabase::addDatabase("QMYSQL", QString::number(this->m_id));
db.setHostName(SERVER_DATABASE_DATABASE_HOST);
db.setDatabaseName(SERVER_DATABASE_DATABASE_NAME);
db.setUserName(SERVER_DATABASE_USERNAME);
db.setPassword(SERVER_DATABASE_PASSWORD);
if( !db.open() ){
...
}
...
This snippet of code is executed inside the run() method of a QRunnable and i have n(n~20) of those Task that run asynchronusly without problems(no duplicated db connections, the connections are removed, ecc..).
The problem is that, after a lot of iteration, the execution crash.
The crash is replicable but not deterministic.
I tryied to run the application in debug mode but the debugger, stop at the line where i call the db.open() function, whitout further information(no stack trace, no signal).
My system specification:
MySQL v5.7.17 (community edition)
Mac OSX 10.11.6
Qt 5.7.0
Any suggestion is very appreciated
When trying to run a program using gdb I get
[New Thread 4612.0x158c]
[New Thread 4612.0x1cb8]
[New Thread 4612.0x11e8]
[New Thread 4612.0x1190]
gdb: unknown target exception 0x406d1388 at 0x746623d2
Program received signal ?, Unknown signal.
0x746623d2 in RaiseException () from /cygdrive/c/WINDOWS/System32/KERNELBASE.dll
I researched this and found three possible causes: (1) path environment variable not set, (2) drive not mapped, and (3) using the wrong version of gdb (32-bit or 64-bit). So I added C:\cygwin\bin to the path environment variable, typed mount and got
C:/cygwin/bin on /usr/bin type ntfs (binary,auto)
C:/cygwin/lib on /usr/lib type ntfs (binary,auto)
C:/cygwin on / type ntfs (binary,auto)
C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto)
D: on /cygdrive/d type ntfs (binary,posix=0,user,noumount,auto)
When I type show configuration get
This GDB was configured as follows:
configure --host=i686-pc-cygwin --target=i686-pc-cygwin
--with-auto-load-dir=$debugdir:$datadir/auto-load
--with-auto-load-safe-path=$debugdir:$datadir/auto-load
--with-expat
--with-gdb-datadir=/usr/share/gdb (relocatable)
--with-jit-reader-dir=/usr/lib/gdb (relocatable)
--without-libunwind-ia64
--with-lzma
--with-python=/usr (relocatable)
--without-guile
--with-separate-debug-dir=/usr/lib/debug (relocatable)
--without-babeltrace
and my computer is 32 bits, so it appears to be the correct version.
gdb itself seems to work, e.g. I can type watch followed by an address and it will set a watchpoint; gcc and g++ work fine, and the program I am debugging will start if I run it from the command line but not from gdb.
What other things should I check?
This is a special technical exception that communicates thread name to supporting debugger (Delphi RAD Studio, Visual Mess etc.). It is convenient to look at the thread list in the debugger and understand what is going on by looking at names. Threads throw this exception and instantly catch it, doing nothing in the handler. Until recent SetThreadName introduction, it was the only common way to set thread name. SetThreadName is Unicode, but SetThreadName not widely supported yet, so many libraries use supported method. It can be IME, OLE, whatever spawns threads.
I guess, gdb is aware of neither method. Just ignore this exception.
I had the same problem. I am also using x86 with eclipse mars.2 on a Vista, and by default, gdb 7.10 was downloaded by setup. I also tried all you have tried to no avail.
Lastly, I noticed the link below and upgraded gdb to 7.11 and the problem was fixed.
https://cygwin.com/ml/cygwin/2016-10/msg00243.html
Is there an error log where I can figure out the error message and line of code in my file which makes the Octave interpreter post the following messages in Emacs?
panic: Illegal instruction -- stopping myself...
panic: attempted clean up apparently failed -- aborting...
Process Inferior Octave aborted (core dumped)
You must use the Octave debugger (take a look at the Debugging section of the Octave manual).
If this was an error message, you could activate debug_on_error. Since it is not, it's a proper crash, you must start on debug mode (enter the keyboard command) and step line by line (enter the command dbstep) until you find which one causes the issue.
Recently I upgraded from 1.4.2 to 1.6.2. Things actually went fairly smoothly, which was relatively surprising. Until I tried to reindex my store. Using the GUI backend gives me the typical no help "Cannot Initialize the indexer process" message. So I tried running indexer.php from the command line (php shell/indexer.php reindexall) which gives me this error:
Fatal error: Uncaught exception 'PDOException' with message 'SQLSTATE[HY000] [2002] Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2)' in /home/shopchau/public_html/stage/lib/Zend/Db/Adapter/Pdo/Abstract.php:129
Stack trace:
0 /home/shopchau/public_html/stage/lib/Zend/Db/Adapter/Pdo/Abstract.php(129): PDO->__construct('mysql:model=mys...', 'shopchau_stage', 'gr8target', Array)
1 /home/shopchau/public_html/stage/lib/Zend/Db/Adapter/Pdo/Mysql.php(96): Zend_Db_Adapter_Pdo_Abstract->_connect()
2 /home/shopchau/public_html/stage/lib/Varien/Db/Adapter/Pdo/Mysql.php(300): Zend_Db_Adapter_Pdo_Mysql->_connect()
3 /home/shopchau/public_html/stage/lib/Zend/Db/Adapter/Abstract.php(459): Varien_Db_Adapter_Pdo_Mysql->_connect()
4 /home/shopchau/public_html/stage/lib/Zend/Db/Adapter/Pdo/Abstract.php(238): Zend_Db_Adapter_Abstract->query('SET NAMES utf8', Array)
5 /home/shopchau/public_html/stage/lib/Varien/Db/Adapter/Pdo/Mysql.php(389): Zend_Db_Adapter_Pdo_Abstract->query('SET NAMES utf8', Array)
in /home/shopchau/public_html/stage/lib/Zend/Db/Adapter/Pdo/Abstract.php on line 144
Now I've tried the various fixes here: delete the locks, delete cache, fixing file permissions, and running checks to see if my DB is corrupt. Far as I can tell, everything else is working. Nothing so far, has helped this issue.
Anyone have any ideas/fixes?
That exception tells about connection problem. Are you sure MySQL uses /var/lib/mysql/mysql.sock socket? Try changing it to /tmp/mysql.sock. You can adjust this in your local.xml