I am analyzing core dump issue . I have run valgrind and look into error log.But I am not able to interpret the following message. Can anyone provide some insight.
I also tried with gdb but I did not get much information. I have looked into other thread and found that it may be centos issue. I am using CentOS release 5.6 (Final) version. I heard that glibc file is not compatible with centos 5.6 but I am not sure about this.Does anyone face this issue any time
==18035==
==18035== Jump to the invalid address stated on the next line
==18035== at 0x0: ???
==18035== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==18035==
==18035==
==18035== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==18035== Bad permissions for mapped region at address 0x0
==18035== at 0x0: ???
==18035== Invalid free() / delete / delete[]
==18035== at 0x47D951D: free (vg_replace_malloc.c:325)
==18035== by 0x3141CD: ??? (in /lib/libc-2.5.so)
==18035== by 0x313D46: ??? (in /lib/libc-2.5.so)
==18035== by 0x47CC3B2: _vgnU_freeres (vg_preloaded.c:62)
==18035== Address 0x198a55e0 is not stack'd, malloc'd or (recently) free'd
==18035==
Jump to the invalid address stated on the next line
This usually means one of two things:
Either you are calling a function through function pointer, and that pointer is NULL, or
You've trashed stack, and return address was overwritten with 0s.
A crash stack trace from GDB might help here.
If this is a stack corruption issue, try using AddressSanitizer (which, unlike Valgrind, does excellent job of detecting stack overflow).
Related
I was developing a C++ program and everything was working fine. Then, while I was programming, I ran make and ran my program like usual. But during the execution of it all, my computer crashed and shut itself off. I reopened my computer and ran make again but this time it gave me a bunch of errors.
Everything seemed off, like my whole computer is corrupted. But everything was working as intended in my operating system except the stuff related to my program. I've tried making a new c++ project, it works just fine. I've tried deleting the project and re-compiling it from github to no avail.
I managed to compile the program in the end but now it gives me a seg fault. The first thing my program does is to print out Starting... to the screen, but this segfault occurs without ever printing that, so it led me to believe that this error is linker related. (Even when the make command was failing, before I fixed it, it told me there was a linker error)
Here is what valgrind says:
turgut#turgut-N56VZ:~/Desktop/CppProjects/videoo-render$ valgrind bin/Renderer
==7521== Memcheck, a memory error detector
==7521== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==7521== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info
==7521== Command: bin/Renderer
==7521==
==7521== Invalid read of size 1
==7521== at 0x484FBD4: strcmp (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==7521== by 0x121377: __static_initialization_and_destruction_0 (OpenGLRenderer.cpp:111)
==7521== by 0x121377: _GLOBAL__sub_I__ZN6OpenGL7Texture5max_zE (OpenGLRenderer.cpp:197)
==7521== by 0x659FEBA: call_init (libc-start.c:145)
==7521== by 0x659FEBA: __libc_start_main##GLIBC_2.34 (libc-start.c:379)
==7521== by 0x1216A4: (below main) (in /home/turgut/Desktop/CppProjects/videoo-render/bin/Renderer)
==7521== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==7521==
==7521==
==7521== Process terminating with default action of signal 11 (SIGSEGV)
==7521== Access not within mapped region at address 0x0
==7521== at 0x484FBD4: strcmp (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==7521== by 0x121377: __static_initialization_and_destruction_0 (OpenGLRenderer.cpp:111)
==7521== by 0x121377: _GLOBAL__sub_I__ZN6OpenGL7Texture5max_zE (OpenGLRenderer.cpp:197)
==7521== by 0x659FEBA: call_init (libc-start.c:145)
==7521== by 0x659FEBA: __libc_start_main##GLIBC_2.34 (libc-start.c:379)
==7521== by 0x1216A4: (below main) (in /home/turgut/Desktop/CppProjects/videoo-render/bin/Renderer)
==7521== If you believe this happened as a result of a stack
==7521== overflow in your program's main thread (unlikely but
==7521== possible), you can try to increase the size of the
==7521== main thread stack using the --main-stacksize= flag.
==7521== The main thread stack size used in this run was 8388608.
==7521==
==7521== HEAP SUMMARY:
==7521== in use at exit: 72,741 bytes in 3 blocks
==7521== total heap usage: 3 allocs, 0 frees, 72,741 bytes allocated
==7521==
==7521== LEAK SUMMARY:
==7521== definitely lost: 0 bytes in 0 blocks
==7521== indirectly lost: 0 bytes in 0 blocks
==7521== possibly lost: 0 bytes in 0 blocks
==7521== still reachable: 72,741 bytes in 3 blocks
==7521== suppressed: 0 bytes in 0 blocks
==7521== Rerun with --leak-check=full to see details of leaked memory
==7521==
==7521== For lists of detected and suppressed errors, rerun with: -s
==7521== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Segmentation fault (core dumped)
turgut#turgut-N56VZ:~/Desktop/Cpp
OpenGLRenderer.cpp:197 is just the end of the file and here is what's writeen in OpenGLRenderer.cpp:111:
static bool __debug = strcmp(getenv("DEBUG"), "true") == 0;
It says that there is an error with strcmp but I've tried using that function on a different project and it worked just fine.
What could be the reason for this? I'm on ubuntu 22.04, gcc verison 11.2.0.
this segfault occurs without ever printing that, so it led me to believe that this error is linker related.
The linker is not involved in your program running, so it can't be "linker related".
There is a dynamic loader (if your program uses shared libraries), so perhaps that's what you meant.
In any case, the crash is happening because OpenGLRenderer.cpp:111 (probably in libGL.so) is calling strcmp() with one of the arguments being NULL (which is not a valid thing to do). This does happen before main.
This line:
static bool __debug = strcmp(getenv("DEBUG"), "true") == 0;
is buggy: it will crash when DEBUG is not set in the environment (getenv("DEBUG") will return NULL in that case).
As a workaround, you can run export DEBUG=off, before running your program and the crash will go away.
It's unclear whether you inserted this line into OpenGLRenderer.cpp yourself or whether it was already present, but it's buggy either way.
P.S. A correct way to initialize __debug could be:
static const char *debug_str = getenv("DEBUG");
static const bool debug = strcmp(debug_str == NULL ? "off" : debug_str, "true") == 0;
P.P.S. Avoid using identifiers prefixed with __ (such as __debug) -- they are reserved.
just trying detecting some potential issues on a small SDL2 program under linux/GCC written in C++17
valgrind report a lot of noisy memory leak about vg_replace_malloc.c that are suggested to be ignored from the official documentation (link)
(Ignore the "vg_replace_malloc.c", that's an implementation detail.)
But later on on the analysis, there is a block of:
==9891== 256 bytes in 4 blocks are definitely lost in loss record 2,243 of 2,414
==9891== at 0x483980B: malloc (vg_replace_malloc.c:309)
==9891== by 0x40156B3: dl_open_worker (in /usr/lib64/ld-2.30.so)
==9891== by 0x4E60407: _dl_catch_exception (in /usr/lib64/libc-2.30.so)
==9891== by 0x40148FD: _dl_open (in /usr/lib64/ld-2.30.so)
==9891== by 0x4EF139B: dlopen_doit (in /usr/lib64/libdl-2.30.so)
==9891== by 0x4E60407: _dl_catch_exception (in /usr/lib64/libc-2.30.so)
==9891== by 0x4E604D2: _dl_catch_error (in /usr/lib64/libc-2.30.so)
==9891== by 0x4EF1B08: _dlerror_run (in /usr/lib64/libdl-2.30.so)
==9891== by 0x4EF1429: dlopen##GLIBC_2.2.5 (in /usr/lib64/libdl-2.30.so)
==9891== by 0x493CC37: ??? (in /usr/lib64/libSDL2-2.0.so.0.12.0)
==9891== by 0x4941DC5: ??? (in /usr/lib64/libSDL2-2.0.so.0.12.0)
==9891== by 0x494C3CC: ??? (in /usr/lib64/libSDL2-2.0.so.0.12.0)
I am wondering if it is some sort of library dependency or a false positive or is obscurely pointing at something related to my code....
Any one could give me more insight how to interpret that definitely lost bytes snippet?
The problem with that output was using SDL2 from package repository that are compiled without debug info.
Therefore recompiling the SDL2 library from source, including debug info, made the valgrind reports a lot clearer and led to solve and understand the issues.
When I run my code I get
Bus error(core dumped)
When I run it with valgrind I get
==26570== Invalid read of size 8
==26570== at 0x67EDEE6: ??? (in /home/carolinaloureiro/Qt/5.4/gcc_64/lib/libQt5SerialPort.so.5.4.0)
==26570== by 0x67F34CB: ??? (in /home/carolinaloureiro/Qt/5.4/gcc_64/lib/libQt5SerialPort.so.5.4.0)
==26570== by 0x4E3D5F4: classA::function1(bool) (in /home/carolinaloureiro/catkin_ws/src/testpackage/lib/libLIB.so.1)
==26570== by 0x4E3DC75: OptoPorts_private::run() (in /home/carolinaloureiro/catkin_ws/src/testpackage/lib/libLIB.so.1)
==26570== by 0x5875383: ??? (in /home/carolinaloureiro/Qt/5.4/gcc_64/lib/libQt5Core.so.5.4.0)
==26570== by 0x55BDE99: start_thread (pthread_create.c:308)
==26570== by 0x65192EC: clone (clone.S:112)
==26570== Address 0x200000001109da98 is not stack'd, malloc'd or (recently) free'd
Could this be because I didn't include a library properly? I've been trying to solve this problem for a while but I am no sure how to.
Thanks
My program (./a.out) encountered with a segmentation fault, so I use Valgrind to check if I can find at which line of code the program corrupts. I got the following output, but I cannot understand them. To me, the most suspicious line of the output is ==17967== Address 0x20687cf80 is 0 bytes inside a block of size 16 alloc'd, does this line means the address 0x20687cf80 is not propoerly allocated a memory block? What can I do to resolve this problem.
I am using a 64-bit linux with 64GB ram.
[root#gpu BloomFilterAndHashTable]# valgrind --tool=memcheck --leak-check=full ./a.out /mnt/disk2/experiments/two_stage_bloom_filter/test/10_10.txt /mnt/disk2/experiments/10M_worstcase_trace/w_10_10.trace 24
==17967== Memcheck, a memory error detector
==17967== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==17967== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
==17967== Command: ./a.out /mnt/disk2/experiments/two_stage_bloom_filter/test/10_10.txt /mnt/disk2/experiments/10M_worstcase_trace/w_10_10.trace 24
==17967==
9998797 Prefixes loaded! //output of my program
==17967== Warning: set address range perms: large range [0x4201a040, 0x6f423220) (defined)
==17967== Warning: set address range perms: large range [0x9c834040, 0x20687cf40) (undefined)
insertion cost time(us): 173168519 9998797 17.318935 0.057740 //output of my program
==17967== Warning: set address range perms: large range [0x23647d040, 0x25647d040) (defined)
Trace loaded! //output of my program
lookup cost time(us): 5728767367 67108864 85.365286 0.011714 //output of my program
==17967== Mismatched free() / delete / delete []
==17967== at 0x4A055FE: free (vg_replace_malloc.c:366)
==17967== by 0x401B13: hash_table_delete(BloomFilter*, char*) (BloomFilterAndHashTable.cpp:503)
==17967== by 0x402212: main (BloomFilterAndHashTable.cpp:687)
==17967== Address 0x20687cf80 is 0 bytes inside a block of size 16 alloc'd
==17967== at 0x4A05F97: operator new(unsigned long) (vg_replace_malloc.c:261)
==17967== by 0x40146D: hash_table_insert(char*, int, BloomFilter*) (BloomFilterAndHashTable.cpp:293)
==17967== by 0x401DD5: main (BloomFilterAndHashTable.cpp:597)
==17967==
Delete succeeded! //output of my program
deletion cost time(us): 178048113 9998797 17.806953 0.056158 //output of my program
==17967== Warning: set address range perms: large range [0x23647d030, 0x25647d050) (noaccess)
--17967:0:aspacem Valgrind: FATAL: VG_N_SEGMENTS is too low.
--17967:0:aspacem Increase it and rebuild. Exiting now.
[root#gpu BloomFilterAndHashTable]#
The "suspicious" output ==17967== Address 0x20687cf80 is 0 bytes inside a block of size 16 alloc'd means, that there is an allocated block of memory, 16 bytes in size. Address 0x20687cf80 is the address of the very first byte of that block (i.e. it's the address of the whole block). So the line itself does only tell you details about a memory block that is involved in the whole warning.
The warning itself is about a "mismatched free()". The following lines show where the free was called:
==17967== at 0x4A055FE: free (vg_replace_malloc.c:366)
==17967== by 0x401B13: hash_table_delete(BloomFilter*, char*) (BloomFilterAndHashTable.cpp:503)
Meaning, hash_table_delete calls free(). Now, why does valgrind think that this is a mismatch? Because the address of the memory block that gets freed (0x20687cf80) was allocated by operator new, which was called by hash_table_insert:
==17967== at 0x4A05F97: operator new(unsigned long) (vg_replace_malloc.c:261)
==17967== by 0x40146D: hash_table_insert(char*, int, BloomFilter*) (BloomFilterAndHashTable.cpp:293)
This is suspicious. If it is the source of your error is another problem, but you should fix it anyways.
The output format is displaying stack so its hard to find the root cause.
==21663== Invalid read of size 4
==21663== at 0x4448117: iurcall_init_rlmgt_IsAllAlcapSuccess(Iurcall_Init_CallCtx_t*) (iurcall_init_rlmgt_p.cc:6319)
==21663== by 0x47D98DD: iurcall_init_rlmgt_IsAllAlcapSuccess_Test_return_1_when_edchMacD_flow_ctx_not_exist_and_alcapEstablish_is_FALSE_Test::TestBody() (iurcall_init_rlmgt_p_test.cc:373)
==21663== by 0x8BCAB27: testing::Test::Run() (gmock-gtest-all.cc:3436)
==21663== by 0x8BD1966: testing::internal::TestInfoImpl::Run() (gmock-gtest-all.cc:3655)
==21663== by 0x8BD1AA8: testing::TestCase::Run() (gmock-gtest-all.cc:3761)
==21663== by 0x8BD1D96: testing::internal::UnitTestImpl::RunAllTests() (gmock-gtest-all.cc:5365)
==21663== by 0x8BD1F21: testing::UnitTest::Run() (gmock-gtest-all.cc:5028)
==21663== by 0x4820149: Gtest_initialisation(int, char**) (iurcall_init_gtest_main.cc:49)
==21663== by 0x808E500: main (bosinit_config_template.h:439)
==21663== Address 0xa8190e4 is 44 bytes inside a block of size 56 free'd
This Valgrind output looks incomplete. It should be something like in this question where the second call stack is printed after Address 0xa8190e4 is 44 bytes inside a block of size 56 free'd.
This call stack is the root cause of the problem. It is not a memory leak. You are trying to work with already deallocated object. The second call stack is where the object was deallocated and the first one is where it was used.