The project written in Fortran runs in different machine fine, but when taken to some other Linux machines it does not. It says segmentation fault on one of them, and on the other it says segmentation fault (core dumped). I did gdb of my program, it is very surprising that it points the segfault to the first line in the program where it should print value of a variable kept in module.
I am compiling all of them as follows:
gfortran -mcmodel=large -fPIC -fopenmp -lgfortran ...
Do you know why this might be the case? The gfortran version is 4.7.2 on Ubuntu 12.10.
Perhaps you need to increase the stack size on those machines. There are answers on this subject on Stackoverflow. Check ulimit.
Related
I fully implemented the content of the following webpage:
http://www.gem5.org/documentation/learning_gem5/part3/running/
The program can be compiled under X86 according to webpage requirements,however I want to get an ARM binary file,so I use the following code to compile it:
aarch64-linux-gnu-g++ -o threads threads.cpp -pthread -std = c ++ 11 -static
I can compile and get the binary file, but I get the following error during running:
erminate called after throwing an instance of 'std::system_error'
what(): Enable multithreading to use std::thread: Operation not permitted
Since the compiled ARM binary file is not provided in gem5's bin folder, does it mean that gem5 does not support running ARM multi-threaded programs, or my compilation options are wrong?
That program fails to run with -static on both qemu-aarch64 and Ubuntu 20.04 amd64 native (always check other more stable platforms :-))
It is known that there are some nongem5-specific problems with -static and threads, see e.g.: when g++ static link pthread, cause Segmentation fault, why?
If workaround mentioned there don't work, you can now also run with dynamic linking as mentioned at: How to run a dynamically linked executable syscall emulation mode se.py in gem5? I've just tested it now and it worked with that example.
And at last note that there is a serious multithread SE Ruby problem which we are not sure how to solve: https://gem5.atlassian.net/browse/GEM5-676
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 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?
I'm trying to compile one of my games on Windows, but unfortunately, no matter what, I'm getting this segmentation fault every time I run the program.
Compilation is successful, and without any warning.
Program received signal SIGSEGV, Segmentation fault.
__chkstk_ms () at ../../../../../src/gcc-4.8.1/libgcc/config/i386/cygwin.S:172
172 ../../../../../src/gcc-4.8.1/libgcc/config/i386/cygwin.S: No such file or directory.
I've tried:
Compiling on a Windows x86 machine
Compiling on a Windows x64 machine
nuwen.net's MinGW distro
TDM MinGW 4.8.1 SJLJ
MinGW builds x86 SJLJ
MinGW builds x64 SJLJ
MinGW builds x86 DW2
I've built all dependencies from source multiple times, tried linking both statically and dynamically.
Debugging doesn't help either - GDB gives me that error message just upon entering main(). I've used -g3 and -O0 flags.
How can I figure out what's happening?
On Windows, the default stack size is smaller than Linux. __chkstk_ms appears to be a function that crashes if you overflow your stack.
You may try to figure out where in your code you are creating huge stack variables or doing very deep recursion, and fix that.
Alternately, you may be able to add a compile flag to increase the stack size. See http://trac.sagemath.org/ticket/13960.
Try to increase stack size. Don't ask me how, I don't know.
The failing call (__chkstk_ms) looks like internal routine which checks if there is enough stack space for the function about to be executed.
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?