Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 4 years ago.
Improve this question
I am working on a IoT linux device. There is segment fault when running my applicantion. I need some methods to solve this problem.
Methods that I have tried:
1.coredump
ulimit -c unlimited; unlimit -f unlimited;
core will create, but maybe the chip's memory is not enough, so the core is always truncatured. I cannot use gdb to get the backtrace.
2.dmesg | grep segfault
This linux system does not save crash in "demsg"
3./var/log/messages
This linux system does not save crash in "/var/log/messages"
Do you have any suggestion to solve segment fault? Thank you very much.
You can use a tool like Valgrind. It helped us a lot when we were trying to find data that is written out of bounds of an array. It is good for checking memory leaks, out-of-boundary cases and segmentation faults. Actually we just used it to check all of our C/C++ programs later and found a lot of undetected bugs.
Note: Don't forget to compile your program with debug information (e.g. '-g' switch of gcc compiler) to get more human readable messages in Valgrind. Check this quick start guide.
Coredumps can be large, but in my experience they contain huge chunks of zeros, so they can be easily compressed. Using the /proc/sys/kernel/core_pattern file, you can get the kernel to pipe the dump through gzip, so that it takes less space ( compressing the core file during core generation ).
Another option would be to try the -fsanitize family of gcc options. More specifically -fsanitize=address and -fsanitize=undefined. If you do that, your application will print a lot of useful information when it crashes (often including the actual file and line number where the crash occured). Oh and don't forget to copy the corresponding shared libraries to your target, otherwise the dynamic linker will throw an error when you try to run the instrumented application.
Related
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 4 years ago.
Improve this question
If the C code is run on windows machine using visual studio, the segmentation doesnt show up and the output is also as expected.
Note: There is lot of usage of pointers in the code for memory allocation and deallocation. The depth of usage of pointers is high (upto 3 levels).
What could be the problem?? The debugging of C code in gdb is also very difficult as it just shows which function is throwing the seg fault and not the line in the code.
You haven't really provided enough information. People here will need more information, to be able to help you. I will update the answer if more details are available.
This is pretty much you can do as of now.
Try to narrow down the problem, and post it here. Certainly, you have limited experience with C, which is okay. But while you may not realise, the details you have given about your program, like "lot of usage" of pointers, or "pointer of pointer of pointer"(3 level), etc, apply to each and every real world C program. Look for the functions where you see segfault.
Are you sure about your conclusion of it works on windows, but not linux. Or it's just an intermittent failure(works/fails sometimes randomly). Try running it multiple times with different inputs(if possible) on both windows & linux to be sure.
Post some details like which compiler you are using on Windows vs Linux. In my experience, I have seen string allocations working differently with different compilers.
Try to post a reproducible piece of code if possible, a small piece of code from your program, that can run independently, and shows similar error. Or at least post the section of code and stack trace of the seg fault. That is how people will have most probability to be able to help you.
If your program is generating a core file on segmentation fault, learn about how to analyse it using gdb, if you haven't done it already. It provides pretty detailed information. In case core file is not getting generated, or it's incomplete/corrupted. Run ulimit -c unlimited on terminal before starting your program, or put this line in ~/.bashrc file.
Learn how to use valgrind. Run your program with valgrind, and see if the generated report shows and invalid reads or invalid writes. Rule of thumb is, you shouldn't be having any of those, unless you are absolutely sure, after getting reviewed, that it's there for a reason. Most of the times, there is always a better way to avoid it. Any such error will either lead you to your issue, or another future issue.
I am trying to program ARM Cortex M0+ MCU. Every alternate time, I get the Stack corrupt error message.
Is there any way to find out what can be the source of error?
I don't know about the way to resolve stack related error
One best practice is to use a static analysis tool to make sure that you are not trampling any stack or heap variables.
Try clang analyzer as an easily available open source solution.
Alternatively, if you can run your code on a host machine, you can use gdb or valgrind to try and find memory errors.
Many times we don't get correct or complete stack dump during crash. My question is in what all cases we can see this to happen.
Probably it can be because of the function call stack getting corrupted. But How such corruption happens.
My 2nd question is how do we debug such an issue and what approach we can take to find the root cause for the crash.
I understand my questions may not have an exact answer but I would like to know your thoughts.
Thank You...
It is operating system and platform (i.e. processor) specific.
The best way is to use a debugger to find such issues (perhaps a remote one, learn about gdbserver)
I would suggest to debug most of your code on a desktop Linux system (because you have lots of useful tools: valgrind, gcc -fsanitize=address, gdb, etc...)
Of course, the call stack can be corrupted to the point of being unusable. Try to memset the stack segment, then return from the function doing that (no matter what tool or trick you would use, the stack is then desperately corrupted on most platforms)!
You might be interested by GNU glibc backtrace function, GCC __builtin_return_address, libbbacktrace by Ian Taylor in GCC
You might also enable core dumps and analyze them post mortem (perhaps using a cross-debugger). See core(5), proc(5), setrlimit(2)
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 4 years ago.
Improve this question
I am working on C/C++ on UNIX and have often seen core files. Many times the core files are difficult to debug to find the actual cause of core or the segmentation fault. Could you please suggest me an efficient debugger?
For segmentation faults, memory leaks, uninitialized data and such, running your program through valgrind is always a good idea. If you are especially interested in memory leaks, the option "--leak-check=full" pays off.
And yes, learn gdb. It takes a little time, but it's worth it.
I think most C compilers on most flavors of *nix support -g to include debugging symbols within the object files, so if you do:
cc -g -c file1.c
cc -g -c file2.c
cc -g file1.o file2.o -o program
./program
Then when you run program if it crashes it should produce a more easily debugged core file. The first two lines just compile source files (producing .o files), the third line tells the compiler to call the linker to link the source files into an executable (passing -g here may not actually do anything if the linker does not have to do anything special to produce an executable with debugging symbols, but it should not hurt anything), and the last line runs the program. You should make sure that you do not tell the compiler to do optimizations when you are trying to debug (unless you find that it does not have errors unless optimizations are turned on) because optimizations typically make the more difficult to follow.
Since I don't know what platform you are on or what tools you have available (or really even what C compiler you are using) so it is difficult to give more specific advice. You should read the man page (manual) for your complier. From the command line type:
man cc
And that should bring up a manual page that tells you lots of things about the compiler on your system. This may tell you how to tell the compiler to produce more warning messages, which could help you find your errors before even running your programs. (note that some warnings may only be produced if you compile with certain optimizations turned on, so even though you probably won't want to debug the optimized program you may want to compile it with optimizations and extra warnings turned on just to see if they tell you anything).
Your Unix system probably has some type of debugger installed. Most Linux machines set up for C development have gdb installed. gdb can be used to run your program in debug mode or to analyze a core file. If you have gdb you can:
gdb ./program
it will start up ready to run your program. If you do:
gdb ./program ./core
it will behave similarly except that it will be as though you were debugging and your program just crashed. From this state the quickest and most helpful thing you can do is to
(gdb) bt
Here (gdb) is the prompt and bt is a command that says to produce a back-trace. That means a call stack, which shows what function the program was in when the failure happened, and what function called that function, and what function called that function, and on and on up to the first function. This can be confusing because it will often show library functions as the most recent called, but this usually means that you have passed in some bad data somewhere along the way that is causing the problem.
gdb is a large and complex program so if it is on your system you should take the time to read up on it.
If it is not on your system then you should find out what similar tools are. Some of the graphical debuggers (either within an IDE or not) act as front ends to command line debuggers and some even support several different command line debuggers, so if you are able to use one of the graphical debuggers you may not actually have to worry about what actual back end command line debugger is being used.
Use gdb. It is the defacto standard Unix C/C++ debugger and as of version 7.0 has reversible debugging features (you can go backwards in time). These reasons alone make it at least worthwhile to check it out.
I really like Totalview. The parallel debugging features are what make me like it as much as I do.
Generally, gdb is an excellent debugger (though it takes a bit to learn). There are also various frontends, some with a GUI, such as DDD or cgdb.
If you explain where specifically you are having trouble, we may be able to better recommend which debugger will help you most.
As suggested above gdb is an excellent debugger. But in the linux terminal debugging larger projects with gdb is little more complex. Simple reason is it is completely command line interface. So i would suggest kdevelop which internally uses the gdb in graphical manner. This debugging tool helped me a lot in debugging my big projects in very easy manner. Let me know if you need any help in using this tool.
This is a hard question to ask because I'm positive I'm about to be bombarded with haters commenting on "if I can't write an operating system already, I won't ever to be able to write an operating system". Well I've read Modern OS by Tanembaum, Linux Kernel Development, Understanding the Linux kernel and others I still don't know if or not I can write an operating system and only by pushing forward to write one will I realise what I don't know. On top of that none of the books I read even bother to describe the boot sequence / compilation sequence.
Anyway I hate to be negative but I would just like to build the example code from the bkerndev tutorial below and have an absolutely minimum operating system:
http://www.osdever.net/bkerndev/index.php?the_id=90
You can download the associated source code in a zip format from here:
http://www.osdever.net/bkerndev/bkerndev.zip
When you try and compile this kernel you run into all sorts of errors caused by the fact that some of the code is broken. Another user was seeking help for this here on stack overflow here:
compiling my own kernel (not from linux-kernel source)
Although didn't get much help. I have addressed those errors by adding the gcc flag fleading-underscores and by changing some of the data types. You can see my code here:
http://github.com/PhillipTaylor/farmix
The code will compile sucessfully and leave me with a kernel.bin executable but when I boot into it from grub I get:
Error 13: Unrecognised or unsupported format (or something to that nature)
When I take the kernel.bin directly from the authors zip file and run it on my eeepc it boots absolutely fine so I think I have a problem with compiling the code correctly. The author is building it from a Windows machine, I believe, but I am trying to compile it using Fedora 10 i386 with GNU GCC 4.3 and I think this is what is causing the issue so I ask you, how do I build a valid executable kernel? Am I missing the correct target or the wrong binary format?
I would really appreciate someone helping me over this embarrassing "first step"
My comment above wasn't very clear. What I meant is "What does the 'file' command report on your kernel.bin vs. theirs?". The output of the linker is a raw binary file. It should start with a few magic words that grub recognizes. They are defined in start.asm near "mboot". I suspect yours is different than theirs.
I don't have nasm handy so I can't build, but you might want to start by comparing the first few words of the .bin file.
It turns out that the line used to compile the app was explicitly set to compile to "aout" format which was what the guide said and what I assumed to be true. Only reading stuff in the "barebones" guide convinced me that I may have been confused. As soon as I changed that one line to "nasm -f elf" it all worked.
This is a tag in my repository that points to a basic WORKING version of bkerndev tutorial code (How to write your own Operating system) for future reference and people who were in my position..
It comes with a makefile for building it from a 32 bit Linux system.
http://github.com/PhillipTaylor/farmix/tree/bkerndev_tutorial_working