I'm running gfortran on a MAC laptop. My program reached a STOP command after a logical check and terminated as expected. But the stop spawned several empty files with the following names: !,calls,date,file,its,make,so,stamp,that,this,to,tsym,update,and will.
I've never seen anything like this before. Can anyone explain the meaning of these files?
I tried a GOOGLE search but did not see useful information.
Related
I am using vim for c++ programming. I have bound the compile command to ctrl+c in vim and I run it in another tmux pane by running ./main.out. My problem is that when my c++ program gives me segmentation fault error, I don't know which line has caused the problem. But when I compiled and ran the program in vscode, it showed me the line that caused the error.
I'm seeking for a way to find out the lines that cause runtime errors like segmentation fault error while running the program's binary file in console.
This is an example output when I do ./main.out:
[1] 24656 segmentation fault (core dumped) ./main.out
When compiling the program, add the -g compiler flag, or even better -ggdb3, which will give you a much prettier output, by adding debugging symbols to the executable. Also, make sure that you compile with the -O0 optimization level.
To actually debug the program, run gdb ./main.out to start the program in a debugging session. If you then run r, gdb will start executing the program, and then stop at the line that gives the segfault.
To figure out how you got to that point, run bt while in the debugging session, and you will get a backtrace, which will show you all the function calls that were made to get to the line of code that crashed.
You can of course do a lot more than this (and you will probably need to, since locating the source of an error is often only the first step). You can use p to print the values of variables, set watchpoints, and many more things. For a while now, gdb even ships with a full fledged python interpreter, so you can even write a python script for your custom debugging needs.
Learning how to use gdb can seem overwhelming at the start, but persevere, and I guarantee the effort will pay off big time :)
Ditto on Adin
Also your code can crash due to a call in which the parameter/s are acceptable but cause the proverbial out of range protection fault from some library somewhere if you don't have those debug versions. If an assembly routine is used inside there, they can do some strange things.
So don't be afraid to add temporary code to help like finding a single call that crashes when 1,000,000 other calls to the same did not.
Is why I like to use a lot of generated randoms if possible to test when you got it fixed.
Installed the MLton compiler on Ubuntu (sudo apt-get install mlton) and had no problems (seemingly) with installation.
When I try to use it (e.g. "mlton test.sml") it sits for a second and then returns nothing. If I try to print something in the file I'm trying to compile, nothing. However, weird part is if I give it bad ML code ("x = 2", without val), it spits out regular errors like "Undefined variable," etc.
I've looked on here, and elsewhere online, and nothing seems to concern what I'm experiencing.
Perhaps I'm just using it wrong?
Thanks in advance.
mlton is a non-interactive compiler; it compiles the program, and that's it. You can run the program later if you want.
So, for example, if test.sml is a valid Standard ML program, then this:
mlton test.sml # compile the program
will compile it and emit a Linux executable file named test. You then run that executable file like this:
./test # run the program
If you want to compile and run the program with a single command, you can use your shell's && feature to run two programs (but only running the second if the first one had succeeded):
mlton test.sml && ./test
Background
I am currently trying to build an autonomous drone using ROS on my Rapsberry Pi which is running an Ubuntu MATE 16.04 LTS. Solving the Computer Vision problem of recognising red circles as of now.
Specific Problem
I am constantly getting the error I get in this question. To help me solve this, I have decided to use gdb. However, the command rosrun --prefix 'gdb run --args' zlab_drone vdstab does not seem to be working for me. zlab_drone is the name of the package and vdstab is the name of the executable I am trying to run. Since this is inside a ROS environment, I have grabbed the syntax from here, and used the suggestions in this question.
When I invoke this command, even with tui, I get a SIGSEGV and when I invoke list inside gdb itself, the program does not stay at a particular point and keeps listing a different line till it is out of range. This is quite a weird issue.
I managed to make it work without this issue earlier by using a different command, I reckon. I just cannot remember how I made it work last time.
Well, in the link you mentioned, it states clear that you should use either :
launch-prefix="xterm -e gdb --args" : run your node in a gdb in a separate xterm window, manually type run to start it
or :
launch-prefix="gdb -ex run --args" : run your node in gdb in the same xterm as your launch without having to type run to start it
So, it really looks like you missed an -ex as #ks1322 suggeseted in the comments or just type run to start the debug process.
I found out about this exclusive bug that relates to Raspberry Pi's solely. Basically the solution involves, as quoted by Peter Bennet:
There is a workaround. Start the program, then from another command
prompt or from an ssh remote login, use gdp -p xxxxx where xxxxx is
the process number. This works without crashing. If you need to debug
something that happens before you can get in from another command
prompt, add to the program a command that stops process at the
beginning of main, for example a call to gets, which will wait for you
to press enter before continuing.
I am Mac OS 10.11 (El Capitan) user. I used 4.6 and when I tried to build some simulation I always get "Simulation terminated with exit code: 139" and couldn’t do nothing at all with that. I thought that when I install 5.0 then everything will be fine, but now I get something like that:
Simulation terminated with exit code: 132
Working directory: /Users/JL_Data/omnetpp-5.0/samples/tictoc
Command line: tictoc -r 0 --debug-on-errors=false omnetpp.ini
Environment variables:
PATH=/Users/JL_Data/omnetpp-5.0/bin::/usr/bin:/bin:/usr/sbin:/sbin
DYLD_LIBRARY_PATH=/Users/JL_Data/omnetpp-5.0/lib::
OMNETPP_IMAGE_PATH=/Users/JL_Data/omnetpp-5.0/images
And when I tried open some simulation in terminal I get:
Illegal instruction: 4
Do you have some idea what can I do with that problem? I tried to find something on the internet, but after one day I do not get any idea.
If you need some more information, please let me know.
As it is right now, your question is not completely clear, since it requires one to be familiar with omnet++ and probably some experience installing and setting it up. However, let me make a couple guesses.
First, Illegal instruction. This usually occurs when the binary was built for an architecture different than the one it's being run on; e.g. when then SSE2 or AVX instructions are present in the binary code, but are missing on the CPU.
See, for example, this SO question:
Find which assembly instruction caused an Illegal Instruction error without debugging
There is also a question that discusses exactly your problem, namely, "Illegal instruction: 4" on OS X:
What is the "Illegal Instruction: 4" error and why does "-mmacosx-version-min=10.x" fix it?
Now, since omnet++ appears to be an open source project, I expect it to have a mailing list and / or an IRC channel. Indeed, here is the communications page on the official website that links to a Google Groups-based mailing list:
https://omnetpp.org/get-involved
https://groups.google.com/forum/#!forum/omnetpp
I advise you to get in touch with the developers with a thorough description of your problem, since the chances of them knowing the solution are significantly higher compared to the chances of there being a user on SO who has faced similar problems when installing an identical version of omnet++ on an identical version of Mac OS X.
Hey guys,
I have written a program to act as a keyboard backlight controller for my MacBook Pro that runs Arch, just like there is natively in OS X. The program itself works great, but the rc.d script I provide with the Arch program package, doesn't seem to open the program correctly ... or so I think.
The source to the Arch package can be found here (rc.d script and PKGBUILD file). I have added "mbpkbdbacklightctl" to the line with daemons in my /etc/rc.conf.
What happens is, that upon start up, I see that the rc.d script starts the program is started without errors, and the backlight on the keyboard is lit on which means the program is also run properly, but then when gdm starts to log in to gnome, the program seems to already have been terminated. I havent been able to find any errors logged, but the program will turn off the backlight if no keyboard or mouse events are registered in 20 or more seconds and turn it back on when one it registered, and this doesnt happen at the gdm and neither in gnome. Also, when I reach gnome and do a pidof -o %PPID /usr/bin/mbpkbdbacklightctl, it returns nothing indicating that the program has been terminated. When gnome is started, I have to restart the rc.d script to make things run properly.
I cant seem to get a grasp on what happens to the program since it is terminated.
The source to the program can be found here, though, I believe that the error is in the rc.d script and that it might not start the program properly for it to "survive" through gdm start-up.
Any ideas to what can be going on?
Regards,
Chris Buchholz
If you read the source code for mbpkbdbacklightctl.cpp you will see these lines:
95 std::string the_display = ":0.0";
96 Display *x11_display = XOpenDisplay(the_display.c_str());
97 if(x11_display != NULL) {
So it will fail if there is no active X server, this means that you have to start this script after X session starts. So you have to put your script under /etc/X11/xinit/xinitrc.d