LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Programming (http://www.linuxquestions.org/questions/programming-9/)
-   -   glibc detected corruption errors (http://www.linuxquestions.org/questions/programming-9/glibc-detected-corruption-errors-860975/)

default5 02-06-2011 12:35 AM

glibc detected corruption errors
 
This is weird. So, I started getting an error message from a qt application I wanted to add a new feature to. The error is: *** glibc detected *** ./myprogram: double free or corruption (!prev): 0x08df0148 ***
A quick hit on google revealed what I thought would normally be the cause, a bad free(). Now, I had upgraded my harddrive to an ssd recently and the code was just copied over from the old hdd, so I thought maybe there was something wrong with my build environment. After a bit of searching, I couldn't find anything. I think I used the same parameters to recompile it and my environmental variables seem to be good.I finally just plugged in the old drive and ran the unmodified, untouched program off of that one. Same error. Now I didn't remember getting that error the last time, so I rebooted into the old drive and ran it. No errors. And then I ran my newly-compiled, fresh-off-the-ssd version and it worked perfectly. Very weird.

If anyone knows what might be causing this, any help would be appreciated. Also, both are running Fedora 13 with 686 PAE kernels and the program in question is a C++ qt app which appears to be generating these errors from a call to QSqlQuery::exec().

Thanks.

ta0kira 02-06-2011 10:53 PM

That error means your program called free twice on the same pointer, which might not always happen since Qt applications take different courses depending on how you interact with them. There are three things that will help:
  1. Try to track all of your new or malloc pointers in the source code to see if they might be freed twice in some cases
  2. Compile with debug symbols and run your program with gdb until you get this error, then run a stack backtrace
  3. Run your program with valgrind to look for allocation-related problems at runtime (you might do this in conjunction with gdb)
Kevin Barry


All times are GMT -5. The time now is 07:44 PM.