I want to start learning C++ but it becomes really irritating when you have to wait up to 3 minutes for a simple two line program to build and run. I've tried multiple things like completely disabling build logging, disabling generate scanner info command inside the discovery options and something else (sorry I cannot remember).
Another thing is that sometimes it's the build that takes a long time, and other times it's the actual opening of the [filename].exe It hits 70% on the progression bar then will just stop for a minute, sometimes I try pressing the run button again and it ends up executing the program twice.
It's not completely necessary that I get this fixed but it would be a big help. Please tell me anything I can do to fix this. No doubt most of you coding in C++ has encountered this at some point.
Related
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've created a small parser that generates an internal representation of an expression from a string. It does compile correctly, but i just can't debug it. When i try to run it, whether it's in debug mode or not, the console pops-up and immediatly closes. In my process list, the program still appears, using 0% cpu and 100 Ko memory, and there is just no way to kill it except by restarting my PC.
The first time i tred using code blocks with the mingw compiler, and the second time i tried using visual studio 2012, but in both case i got the same problem. When trying to run it with VS it showed an error message saying something like "abort has been called".
I can provide the source code if really needed. I'm not using anything extraordinary in it, just pure standard C++ language and iosream to display results and errors in a console.
What can this be due ?
Thanks for your help :)
I have a really large code and when I try to run it in codelite, the codelite interface becomes non-responsive and I have to kill it. This usually happens in case of infinite loops.
I tried to put breakpoints in multiple places of the code to find the problem, but no luck so far. The execution halts after a while from the time that I start running the program. What is the best way of detecting such infinite loops? Codelite doesn't have a "stop" button AFAIK.
EDIT:
I ended up adding a lot of cout statements and ran the executable in a terminal rather than gdb. This helped finding what the program is doing after a really long time.
The simplest approach is to run the code for a while and then use the debugger to suspend execution without using breakpoints. If you are lucky, the call stack should indicate the bit of code that you are getting stuck in.
Failing that you will need to pepper your code with logging statements.
after I compiled my project in C++ (VisualStudio) around 3-4 times, I can do it anymore due to LNK1168 that stands for "VisualStudio can't write into the exe". I've looked up in my TaskManager, the exe is NOT running. Normally I have to wait for like 5 minutes but that isn't a real solution. Any ideas?
ProcessExplorer just tells me, that the handle is invalid and though can't be closed. It remains open all the time...
First thing that comes to mind is to use ProcessExplorer to figure out what process is keeping the file open. Download and start up the tool en select Find from the menu. Enter the (partial) file name and it should show up in the search results. Double click to jump to the process and file handle in the main application window.
I'm guessing Visual Studio is the culprit.
Fortunately, you can also use Process Explorer to close the handle. Right-click and choose Close Handle.
Note that it's not a good idea to go around closing file handles on a regular basis. However, whenever you're in a pickle it can really help solve annoying problems.
If I recall correctly, a similar problem existed way back in VS 6. It had to do with incremental compilation. For a more structural solution, try doing a full rebuild from time to time or disabling incremental compilation all together.
I have been experiencing exactly the same problem (For C# and C++). I have just discovered that having the Application Experience Service disabled seems to cause EXPLORER.EXE To keep .exe files hanging around (locked by the SYSTEM) for several minutes after running that executable.
The solution to this problem, for me at least, was to re-enable the Application Experience service. (I had originally disabled it since it seemed unnecessary - Apparently I was wrong!)
Your exe might still be running. Stop it before recompiling it.
I am trying to compile a rather big application on Solaris. Compiling it on AIX caused a problem that the command line buffer was too small (ARG_MAX).
On Solaris it compiles most of application successfullym but then it just hangs and without any error hangs an do nothing for at least an hour.
I am running it on SunOS 5.10 Sparc 32 bit.
Any ideas on how to find out what's going on or what might be causing such behavior?
I can't tell if the compilation is hanging, or your app itself.
If the app is hanging just follow the usual debugging steps: Either run it in your debugger and watch when it dies, or add print statements.
If the compiler dies, does it always die on the same file? If you compile that file by itself does it still hang? If so, try trussing the compiler when you try to build the file that hangs. You may find that it's blocking on I/O waiting for some nonexistant file or something similar.
What you may have to do is:
Comment out or delete 99% of the code and compile that
Add around 5% of the code back in and compile that
if the last thing you added caused the hour hang then split it up
Back to step 2
Just for those who encounter this in future.
The problem was optimization flag causes it to take a REALLY long time to compile. I am talking 1+ hour for one cpp file.
This is big project.
In addition there was an issue with Sys Admin on SUN box not giving me enough CPU share.
Increasing that solved this problem, well made it quicker and within reasonable time bounds.
I hope this helps