valgrind: m_mallocfree.c:303 (get_bszB_as_is): Assertion 'bszB_lo == bszB_hi' failed. valgrind: Heap block lo/hi size mismatch: lo = 80, hi = 4607182418800017408. This is probably caused by your program erroneously writing past the end of a heap block and corrupting heap metadata. If you fix any invalid writes reported by Memcheck, this assertion failure will probably go away. Please try that before reporting this as a bug. host stacktrace: ==55868== at 0x38077382: show_sched_status_wrk (m_libcassert.c:341) ==55868== by 0x38077382: report_and_quit (m_libcassert.c:413) ==55868== by 0x38077382: vgPlain_assert_fail (m_libcassert.c:479) ==55868== by 0x3808B73E: get_bszB_as_is (m_mallocfree.c:301) ==55868== by 0x3808B73E: get_bszB (m_mallocfree.c:311) ==55868== by 0x3808B73E: vgPlain_arena_free (m_mallocfree.c:2044) ==55868== by 0x380048BA: release_oldest_block (mc_malloc_wrappers.c:165) ==55868== by 0x380048BA: create_MC_Chunk (mc_malloc_wrappers.c:208) ==55868== by 0x38004F93: vgMemCheck_new_block (mc_malloc_wrappers.c:366) ==55868== by 0x38004F93: vgMemCheck___builtin_vec_new (mc_malloc_wrappers.c:405) ==55868== by 0x38107599: do_client_request (scheduler.c:1840) ==55868== by 0x38104B69: vgPlain_scheduler (scheduler.c:1406) ==55868== by 0x38119288: thread_wrapper (syswrap-linux.c:102) ==55868== by 0x38119288: run_a_thread_NORETURN (syswrap-linux.c:155) sched status: running_tid=1 Thread 1: status = VgTs_Runnable (lwpid 55868) ==55868== at 0x4A066E1: operator new[](unsigned long) (vg_replace_malloc.c:392) ==55868== by 0x42A0BB: Value_Derivatives (adiff.h:134) ==55868== by 0x42A0BB: operator*<double> (adiff.cpp:230) ==55868== by 0x42A0BB: int Model::objective<Value_Derivatives<double> >(Value_Derivatives<double>*, Value_Derivatives<double>&) (model.cpp:482) ==55868== by 0x42CBAF: void Model::gradient<double>(int, double*, double&, double*) (model.cpp:538) ==55868== by 0x42633B: Model::real_fun(int, double*, double&, double*) (model.cpp:218) ==55868== by 0x425948: real_L_obj_grad(int, double*, double&, double*, Result&, Model*) (lbfgsbsl.cpp:57) ==55868== by 0x425D84: lbfgsbsl(int, double*, double*, double*, double&, Result&, Model*) (lbfgsbsl.cpp:148) ==55868== by 0x426101: getUpperBound(int, int, interval*, Result&, Model*) (getupperbound.cpp:77) ==55868== by 0x423339: intbis(Result&, Model*) (intbis.cpp:75) ==55868== by 0x421A97: main (genbis.cpp:35) Note: see also the FAQ in the source distribution. It contains workarounds to several common problems. In particular, if Valgrind aborted or crashed after identifying problems in your program, there's a good chance that fixing those problems will prevent Valgrind aborting or crashing, especially if it happened in m_mallocfree.c. If that doesn't help, please report this bug to: www.valgrind.org In the bug report, send all the above text, the valgrind version, and what OS and version you are using. Thanks.
Have you ruled out problems in your program as advised by the message?
Yes. I have checked my code as carefully as I can but I didn't know what the problem is. When I run my program, it aborts and says "glibc detected. double free or corruption". So I checked and found the program abort when trying to delete a pointer. I checked the creating and deleting of that pointer but no problem found. But the Valgrind here seems to tell me the problem happens when I try to create a class. So it confused me.
So there are no other valgrind messages before that one?
Yes, you are right. There are some Valgrind messages hiding among my output before that one, which are consistent with my findings when running the code. I have fixed them now. Thank you. But the problem in my main description still remains. I checked and found it happens when a function fails to returning 1. More specifically, when the function ends and a class should be destroyed, the pointer in that class cannot be deleted. My code for destroying the class is like the following: ~DerivativesII<Type>(){ if(df) delete []df; if(df2) delete []df2; } When I add some output sentence before and after the pointer-deleting sentence and run again, I found the program keeping deleting those two pointers many times. It's weird because I don't have a loop here.