I'm have been working on this c file for some time and regularly saving it each time i execute the code. All of a sudden i can't save the file due to an error: "cannot save file D:\Applications\C\C_files\no_of_days.c"
Here's a screenshot.
I have been having the same error while trying to save different c files for a few days now (this never happened before).
On googling the error, i found only one suitable answer, there it was suggested to not use folder names with spaces for saving programs in dev-c++.
I did that but the problem still persists.
This is my first time asking a question on stack overflow, so forgive me for any mistakes that i may have made.
Edit: As a temporary solution for this issue, I copied the code and pasted the code into a new file and save it with a different name. After a few times of saving and execution, the same error occurs.
I did the abovementioned steps(making a new file....) 4 more time, and each time, after a few saves, the same error occurs.
The problem was google sync.
Dev-c++ couldn't save the file after editing it as google sync was using it for a long time even after it was synced.
I paused google sync, restarted my computer and then the files could be saved again.
Related
While trying to crate a new file, or open an old code in Dev c++ an error pops up. the error message is :
'clBtn' is not a valid integer value.
I've had this problem for a couple of days now. I have three options, to send anonymous bug report, to continue or to terminate. I don't think I deleted something that lead to this issue. Also I have never had this issue before, any advice would be helpful.
I couldn't find a solution to this problem. I have a very simple program to generate a PDF using JAGPDF. If i am opening the program from visual studio (same input, same parameters) it runs to the end without errors 90% of the time, but sometimes it throws an exception telling me that symbols not loaded for jagpdf-1.4.dll
If I run the executable directly, 90% it creates the PDF correctly and 10% of the time created a corrupted pdf that I cannot open. How can I solve this problem?
EDIT: I put a screenshot of the error I'm getting, it is very dificult to reproduce because the program runs normally about 90% of the time, so I have to press build several times until it crashes...
EDIT 2: Since it seems the bug is from the library, (I already send them a message reporting it but doubt they'll do something about it because last release was years ago).
I sort of solved the problem by wrapping the function around a loop using try and catch where if the first time it fails then the exception is caught and the function is tried again until it passes. I put a limit of 10 times it can run the loop before terminating it.
The thinking was that, as the events seem to be statistically independent, the loop will reduce the chance of it failing from 0.1 to 0.1^n with n the number of loops.
So now the program is crashing with a probability of 0.0000001% instead of 10%.
With this fix I am happy to report no fails for this weeks data.
Thank you all for pointing me to the direction of the error.
It sounds as if you have found a bug in the PDF library you are using. You have to file a bug report with the PDF software provider. Hopefully they can provide you support.
I'm a beginner C++ developer working on a quality assurance project utilizing the GoogleTest framework. While creating unit tests, to verify whether solution outputs were within an acceptable range or not, I received the error message of " LINK1104: cannot open file 'C:Users\kfung\Documents\SAM\sam_dev\ssc\build_vs2017\x64\Release\test.exe' ".
It came out of nowhere. I've been working within the SAM\sam_dev branch for quite sometime now, where I have complete access to this. On top of that, this error message came after trying to build my solution. When this message came, I was only changing integer values, so I do not think it really is linked to that action. It wasn't anything major.
The test.exe program works fine and is able to test all of the files within my test explorer. The program works, yet VS17 is unable to locate/use this file.
I've searched throughout stack overflow and google and nothing like my issue has been discussed. The error has came out of nowhere with nothing really to prompt it.
I've tried "resetting" my development branch on Gitbash using the commands "checkout -- . ", where I should have reverted my project to it's workings state before this occurred. This did not effect my solution where the error keeps occurring.
What should I do?
newbie here. I am following along this SFML flappy bird tutorial. I am currently stuck at this portion of stage creation where a "Splash State" (or logo loading screen) is made. The code of which is exactly the same as what is shown here.
I am using xcode 10.1.
The project builds. But when I tried running it, it crashes and I am greeted with the following:
Failed to load image "Resouces/res/Splash Background.png". Reason: Unable to open file
libc++abi.dylib: terminating with uncaught exception of type std::out_of_range: map::at: key not found
(lldb)"
If I understand it correctly, it's saying it cannot perform the action of loading the image at the aforementioned path because it is not able to open "libc++abi.dylib". And now the program is being terminated. (please help me understand this problem better by either confirming or correcting me here).
When I tried looking for "libc++abi.dylib", it is missing. Instead, I can only find "libc++abi.td".
This thread says to add that under Link Binary With Libraries. That did not produce any result.
The tutorial shows that the code runs and a "Splash State" or logo screen is expected to appear. Instead my program crashes and I am greeted with the aforementioned error.
I was wondering if anyone else ran into similar issues?
It's solved. It is made by a typo on my end... sorry.
I'll try my best to explain it here for those of you who may have the same issues:
The game asset is governed by a map, which is a private member variable of a "AssetManager" class. The typo is at the file path. Because of this, the map never inserted the key since the file path isn't valid.
When the map is later accessed, it would be out of range since nothing ever got inserted (since the asset did not load).
Basically, the error of not being to open "libc++abi.dylib" is caused by the map being out of range.
During runtime my program creates and writes two large binary files simutaneously to the disk. File A is about 240GB, file B is about 480GB. The two files are maintained by two ofstream objects, and the write opertations are performed with the member funcion write in a loop.
Now the problem is: The write file operation fails everytime the whole write file procedure reaches 63~64%. The first time it failed on file A, and the second time it failed on file B.
During the program runs these days, the power supply of my building happens to be under upgrade. By a strange coincidence, every time the program failed, the electrician happened to be cutting and resuming the power supply of the central air-conditioner and some offices. Therefore, I really wonder whether the write file failures were caused by unstable power supply.
I'm sure that the failure is not caused by file size limit, because I've tried to write a single 700GB file using the same method without any problem.
Is there any way to find out the detailed reason? I feel that the flags (badbit, eofbit and failbit) of ofstream don't provide too much information. Now I'm trying to use errno and strerror to get the detailed error message. However, I see that a possible value of errno is EIO, which measn "I/O error", which again provides no useful information.
Is there anyone who encountered this situation before?
By the way, the program runs without error when the sizes of file A and file B are small.
PS: This time the program fails at 55%, and the errno value is EINVAL: Invalid argument. Very strange.
Confirmed, the cause is indeed a bug of NTFS: A heavily fragmented file in an NTFS volume may not grow beyond a certain size. This means that CreateFile and WriteFile cannot fundamentally solve the problem, either.
All right, I've solved the problem with Win32 API: CreateFile and WriteFile.