Ever got one of those *really* annoying glibc errors that don’t give you a whole lot of information except “something bad happened, and it was memory related, but we’re not going to tell you where the problem is!”? You know, in the form of<\/p>\n
*** glibc detected *** .\/test: double free or corruption (out): 0x0000000001e52440 ***\r\n======= Backtrace: =========\r\n\/lib\/libc.so.6[0x7f27a9fd5a58]\r\n\/lib\/libc.so.6(cfree+0x76)[0x7f27a9fd80a6]\r\n.\/test[0x401e51]\r\n.\/test[0x401e83]\r\n.\/test[0x402118]\r\n.\/test[0x402159]\r\n.\/test[0x40155b]\r\n.\/test[0x40167d]\r\n\/lib\/libc.so.6(__libc_start_main+0xe6)[0x7f27a9f7a466]\r\n.\/test[0x400cd9]\r\n======= Memory map: ========\r\n... and so on ...<\/pre>\nI’ve encountered this cryptic and annoying error (I mean c’mon, usually the memory addresses referenced in the trace don’t resolve to anything in gdb) a few times for really random and weird memory-related errors, many times when I’m doing something with the STL.<\/p>\n
Turns out, you can define __GLIBCXX_DEBUG in your program (using -D__GLIBCXX_DEBUG on the g++ command line), and instead of an annoying message you may get an assert that is far more helpful and looks like this:<\/p>\n
\r\n\/usr\/include\/c++\/4.3\/debug\/vector:267:error: attempt to access an element\r\n in an empty container.\r\n\r\nObjects involved in the operation:\r\nsequence \"this\" @ 0x0x7fff5ee0f420 {\r\n type = NSt7__debug6vectorIiSaIiEEE;\r\n}\r\n<\/pre>\nNow at least you know what you did wrong. However, for optimal usage you should be attached with GDB, and then as soon as the error occurs you can do a backtrace with the debugger and you should know exactly where the bug is. The only caveat is that there is a noticeable performance hit when you enable this (especially if you use the STL heavily), so in general you don’t want to define it all the time. <\/p>\n
Hope that saves you some time! I know it helped me!<\/p>\n","protected":false},"excerpt":{"rendered":"
Ever got one of those *really* annoying glibc errors that don’t give you a whole lot of information except “something bad happened, and it was memory related, but we’re not going to tell you where the problem is!”? You know, in the form of *** glibc detected *** .\/test: double free or corruption (out): 0x0000000001e52440 […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[42,31],"tags":[],"_links":{"self":[{"href":"http:\/\/www.virtualroadside.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/227"}],"collection":[{"href":"http:\/\/www.virtualroadside.com\/blog\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/www.virtualroadside.com\/blog\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/www.virtualroadside.com\/blog\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/www.virtualroadside.com\/blog\/index.php\/wp-json\/wp\/v2\/comments?post=227"}],"version-history":[{"count":3,"href":"http:\/\/www.virtualroadside.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/227\/revisions"}],"predecessor-version":[{"id":232,"href":"http:\/\/www.virtualroadside.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/227\/revisions\/232"}],"wp:attachment":[{"href":"http:\/\/www.virtualroadside.com\/blog\/index.php\/wp-json\/wp\/v2\/media?parent=227"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.virtualroadside.com\/blog\/index.php\/wp-json\/wp\/v2\/categories?post=227"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.virtualroadside.com\/blog\/index.php\/wp-json\/wp\/v2\/tags?post=227"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}