I tried to run this code [the-git-link] (https://github.com/DropIn/SequentialTextReading), but I experience a "Segmentation fault (core dumped)". Do you have any idea about this error? I am running it on Ubuntu 14.4 and
the code is too big to use traditional debug methods on it like using gdb.
Any idea how to solve this problem or what tools should i use to solve it knowing that there are many files and main in the project?
You can also load your coredump to gdb and find the root cause, after your program crashed.
You may benefit from reading How to generate core dump file in Ubuntu, and How to analyze a program's core dump file with gdb?
Related
I am working on a large codebase and trying to debug the same using gdb(C/C++) extension on VSCode.
On running a particular configuration, I get an error with exit code 139. I know this is a segmentation fault, but am unable to exactly pinpoint where the seg fault is occurring. Is there any way I can monitor that?
Probably some file that I am missing where the details are being captured?
I can debug segfault using gdb from the terminal. But since the code requires certain configurations and is spread over hundreds of files, I am not sure how to do that.
I'm currently struggle to unterstand a certain behavior which randomly happens after a software build. The software consists of multiple modules and, after building it, it will exit with a segmentation fault during execution.
I've identified two different steps during execution where this behavior happens.
The software exits with seg fault while executing a certain task.
The software exits with seg fault after completion of the task.
And in some cases, no seg fault occures at all. The problem is, that using a debug build, will only show me the cause of the second case (which is caused by a call to a third-party library). But I'm not really able to identify why this is happing.
It's a 32 bit build using gcc (SUSE Linux) 7.5.0.
You could use valgrind to check your program for any memory issues
I am running a multi-threaded C++ program in a Linux system which has android on it. I am getting a crash due to SIGSEGV 11 (segmentation fault). A backtrace generated shows .so file followed by heap with some address.
How to check where exactly the segmentation fault has occurred? How to debug the address which gets printed in the backtrace?
Use adb logcat to get the logs. The extra info (callstack, registry) there should help you identify the issue.
To translate addresses in source line use addr2line available in NDK
I have a simulation that I am trying to profile it with gprof.
I didn't write it and I am not allowed to add any code. Normally the program runs without errors. It is written in C++.
While program running, when I try to change the volume of the system from keyboard, the program gives the error: Segmentation fault (core dumped) every time.
My system is Linux 3.8.0-37-generic #53~precise1-Ubuntu x86_64 x86_64 x86_64 GNU/Linux.
Does it arrive because of the code, which runs perfectly in other systems ? If not what could be the reason? How can I avoid it?
I have a big project solution that I am trying to execute, it builds perfectly fine in both release as well as debug mode. The problem is when I try to execute it the debug one is fine but release mode creates segmentation fault and creates a core dump.
Now can anyone help me about how to find out the line number in the code that might have caused the segmentation fault. I tried using gdb but couldn't do much.
Now can anyone help me about how to find out the line number in the code that might have caused the segmentation fault.
Not with the information you've provided (which is insufficient).
You should read GDB documentation. Here is a good place to start.
You should load the executable and core into GDB, and use where command to fund out which function you are crashing in.
Since the crash only happens in "release mode", you'll need to figure out how to add -g flag to your release mode build. Once you've done that, GDB will tell you the file and line number where the crash happens.