I was debugging an executable_file which is generated from C++ codes. When I was in the middle of a GDB session, I changed the source.cpp files and recompiled them to regenerate a new executable_file. Now, GDB is running the old deleted executable_file, even though I have deleted that old file from my system. How this is possible? How can I force GDB to run the new executable_file?
UPDATE:
After restarting the system, everything worked fine for the first compilation, and I could run the new executable_file. But I am observing the same issue for the next compilations. Nevertheless, when I remove executable.o and recompile everything look fine.
Is this because of an issue in my makefile? Or I have broken something in my Unix system?
When you delete a file that's being used, Unix will remove the file from the directory, but the file will still exist until the last user is done with it.
To force gdb (or any application in this situation) to use the newest version, restart the application (or reload the file into the application if that's an option).
As a point of comparison, if you were running on Windows, you'd get an error regenerating an executable while the file is already in use.
Update: If you're doing this frequently, consider modifying your makefile to append a revision number to the generated executable. Each executable would have a unique name, and this would help avoid confusion about which file you're using.
Once a program, library, etc. is loaded into memory, it can be deleted but still be able to run. Once the program is closed and restarted, you will be running the new program.
An instance of where this is problematic is the many times I've deleted a library or executable that my Linux box needed to run. Once I restart my computer, I soon realize that I messed it up ...
Fun times.
By way of example,
/*
Compile me.
Run the executable.
While the program is running, delete the executable/binary.
The program will continue printing the message.
*/
#include <stdio.h>
#include <unistd.h>
int main () {
while (1) {
printf("I'm still running.\n");
sleep(2);
}
return 0;
}
To answer your question, close the currently running gdb session. Then start a new one, using your new executable.
PS: If you started it before you deleted it, you're still running it. (Where it is the old program.)
Related
I have read through most of OpenMesh's documentation, and am lost in how to run a simple program using OpenMesh. I followed the tutorial for making a basic cube and building the project: http://www.openmesh.org/media/Documentations/OpenMesh-6.2-Documentation/a00068.html but nowhere do they mention how to RUN the program. The tutorial says to put the file that makes the cube in a particular folder: http://www.openmesh.org/media/Documentations/OpenMesh-6.2-Documentation/a00066.html and I did this. It clearly compiled the code when I built it with cmake and make. After that I am lost.
Assuming you used the CMakeLists.txt as given in the page you linked as-is, the linker should create a file MyOwnProject within the directory where you executed cmake and then make. That's your executable. To run your program, execute that file, either by double-clicking it within a file manager (Explorer, if you are on Windows) or by typing ./MyOwnProject on a Linux command line.
I am trying to get some code running which uses make. I've downloaded and installed both MinGW (standard 32 bit) and TDM-GCCs flavor of MinGW on my 64-bit Windows 7 machine.
When I run make (i.e. mingw32-make.exe) in Administrator mode, I get the following error message:
Windows cannot access the specified path, or file. You may not have the appropriate permissions to access the item.
The weird/scary part is that, upon running, it immediately deletes the exe file.
I ran a checksum SHA1 as recommended in the comments using the Microsoft (R) File Checksum Integrity Verifier V2.05:
C:\path\to\folder>fciv.exe -sha1 mingw32-make.exe
//
// File Checksum Integrity Verifier version 2.05.
//
c8ae5c780ab7bed652883d6443b5bfe5e23d30c9 mingw32-make.exe
I don't understand what this output means, but maybe it's helpful to someone.
Notes:
This happens regardless of where the file is located on my pc.
This behavior is specific to the make program (others such as gfortran and gcc appear to be working fine)
Renaming the file makes no difference.
I am an administrator on the pc
Same behavior when I run the program from the explorer or command line.
My anti-virus program (Avast) does not detect any problems with the file when I scan it.
I got the MinGW setup file from this SourceForge page.
I got the TDM-GCC web installer from this page.
The file size is 219,662 bytes (from both the main MinGW and TDM-GCC packages)
I have run make from the command line where I have started the command prompt by way of selecting Run as Administrator in the context menu.
I have also tried to run make by selecting Run as Administrator when I have it selected.
I run the command mingw32-make when this behavior occurs. I have also tried renaming it to things like make and foo with the same result.
The first time this happened with both MinGW it deleted the original file and I re-installed it using the mingw-get application. From thereon after I started making copies of the original mingw32-make for testing.
For the make executable, I have all permissions (including Read & execute) except the special permissions field.
After using the process manager I found out it was indeed Avast that was the problem :S A couple of lines revealed avast actually deleted the file before windows got around to executing it, which was the reason for the windows message. I put Avast on 'Silent Mode' a while back; I thought the only purpose of this mode was to suppress notifications about minor updates, but apparently it also gave Avast permission to deal with 'threats' silently as well.
After figuring that out the solution was straightforward. I just went into the settings and created an exception for the mingw32-make.exe file. It now runs without issue.
Thanks very much for your help everyone!
User account has administrator privilege but when user started to work , not all privilege are taken in account , just start your application for compiling with run with administrator mode try this : https://technet.microsoft.com/en-in/library/cc781763(v=ws.10).aspx
Preface: Using cygwin on a Win7 machine.
I have some old (very old) f77 code (45,000 lines in 25 files) written by someone else that I am trying to use.
Yesterday I compiled, linked and ran it OK (using f77 compiler). I then made some mods (increasing array sizes) and kept getting segmentation faults when executing. Wondering if there was a compatibility problem I then fiddled with the settings in Windows (to no avail).
Now I cannot even run the compiled program - I get a "cannot execute binary file" error. I cannot even compile and run the original version of the code.
There were only some minor warnings during the compiling and none during the linking.
I have:
Checked permissions (all OK:- user::rwx)
Checked via file and get: "PE32 executable (console) Intel 80386, for MS Windows".
Written a test program to check my compiler commands and it ran as expected.
Copied all source code to another directory to see if that was problem (it didn't help).
Tried to run the executable from a windows command prompt and get "not a valid Win32 application" (and yet a previous executable executes OK).
What may have happened between yesterday and today that is stopping this program executing. Is it related to my fiddling with the compatibility settings? Or is it something in the code that lets it compile and link OK but not execute?
Any ideas appreciated.
I have compiled my kernel(linux-3.6.6) with success in the debian linux version(12.04).(LinuxPraxis ->is the name of my new version) then I made some modification on Read_write.c file ("I mind I write there some printk to get a message when a named pipe is writting and when it is reading").
Now I hear that I need to recompile my new version. please help me to understand it.
Shall I need to recompile my kernel completely or it is another way to recompile a kernel?
Use "make -j5" to rebuild your kernel image file for host system with 4 cores.
Then run "make install -j5" to install kernel image file.
The "make install" will compress your kernel image file, copy kernel image to /boot and run grub-update to update the grub config file.
If you have already compiled, the Makefile takes care of only recompiling the parts which depend on the changed file(s). There could still be multiple files which depend on it, but the effort should be significantly smaller than the initial compilation nevertheless. You don't have to do anything differently, the compilation works the same; files which already exist on disk which do not depend on the changed file will simply not be recompiled.
I'm reinstalling everything on my machine, and amongst those is Cygwin. I'm trying to avoid reinstallation, partly because I don't even know what it is that I've installed. Can I just move the Cygwin directory from one machine to another and expect everything to work, or are there some other important settings that I need to move as well?
As far as I saw, it's pretty self-contained, but one never knows.
Yep! Go for it. You won't encounter any problems.
You can just copy the entire cygwin directory to your new machine, open up the cygwin shell and everything (as long as you are only calling cygwin-internal programs and stuff that's within the path) will just work as if you you are working on your old machine.
The only thing you'll loose is the directory where the "already downloaded and compressed" packages for a possible re-installation are stored. Fortunately this directory is optional, so no problem for migration to another platform. You could copy that directory as well, but most likely all the packages that you have are outdated anyways and a run of setup.exe would fetch the new versions anyway...
Btw - since someone said exactly the opposite some real-life experience: I use this feature quite often with success. I've copied my cygwin dir to USB-sticks and used it on friends computers. I also copied it to the laptop of my fiance when we go to holidays and take a laptop with us.
It always worked without any problems....
The short answer is: No, you can't copy the whole Cygwin folder. You just copy the configuration files(bash files, vim file, etc.) you need.
The long answer is: If you copy the whole Cygwin folder, it may work in some case, and may not in some other case.
The reason is: you will lose linux file mode when copying files on Windows. And that will cause a lot of troubles. However, you may not have the troubles when you use Cygwin just like a common Windows Program(which means you don't care file mode and anything related), and run it as Windows Administrator(which is not required when Cygwin is installed as usual).
BTW: you can export the packages you installed by cygcheck.exe -c and install them on the new Cygwin. You can also install/update Cygwin packages by Cygwin's setup-x86_64.exe in command line like:
setup-x86_64.exe -q -P package1,package2,package3
No, you have to reinstall it from the cygwin installer, sorry!
Most importantly you'll want to copy everything from your home directory (default is c:/cygwin/home/) especially anything w/ a "." in front of the filename.
As for individual application preferences, etc., you may lose those -- but if you do the reinstall while you still have access to your old machine -- you can probably get to 90% of your previous install without too much trouble.
My experience with copying from one cygwin64 (I don't think there is a difference) to another machine is that all of the symbolic links got crushed:
As an example:
What used to be /usr/bin/cc -> /usr/bin/gcc.exe (or something like that)
After the copy /usr/bin/cc became a text file containing the string:
!<symlink>/usr/bin/gcc.exe
My method of copy was merely cp -r /cygwin/c/cygwin64 <dest>
My dest was a FAT32 FS, but I don't think that had anything to do with it.
There were also characters 0x00 and 0xFF sprinkled among many of these 'text' files so that they appeared to be binary.