We have a user who ran a full compile from the AOT during the day. What is the impact? So far nothing bad has happened. I know your not supposed the close the compile job window under any circumstances.
Ok, so the system was really, really slow for about 4 hours, but AX was still functional. There was one class with external dependencies that did not compile correctly, and we logged into each AOS and ran a restore and compile on that one class. We are going to run a full compile this weekend, but everything seems to be running fine now.
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 have been using Google Tests that someone else put together for me and it has worked great...until today. Now when I try to run a test I get a very mysterious problem and I am dead in the water. I had the IT guys even recreate my profile which did have some issues etc - still the same error with little to go on:
Any ideas? Anything. Dead in the water here.
If I don't try to run an individual unit test as I was doing, but simply press F5 from the testing framework (something I had never done actually as I always ran tests through the unit test framework) you can actually find a place where your program pukes.
My program was puking somewhere that had absolutely nothing to do with my unit test, so under the hood, it is clear that the framework needs to run and initialize a lot of stuff that has nothing to do with my tests - in this case it initialized an input stream from a file it could not find way outside of what I was doing. Once I tracked that down, we were good again.
It was very counterintuitive that something so orthogonal to what I was doing caused this. Resharper said they would try to give better error messages in the future.
basically, I have a native C++ application which obviously crashed from time to time during code development. After fixing some bugs it runs rather smoothly. However, I noticed a rather weird behaviour which is very confusing to me.
It is a CMake-based project and I have an option of packaging the application into a zip file. When I run the executable from a freshly extracted zip - the application runs normally (and performance is high). However, say, if it crashes couple of times - the next start the behaviour is the same, but everything runs terribly slow. The test case I have (albeit manual) is very straightforward and I can repeat it easily.
Once the application is slowed down all I have to do is to rename the folder the application is located in and the performance rises again. Until it has crashed couple of times.
Obviously, this is not a problem once I get rid of the crashes. However, it seems to me that once the system (Win8.1 x64) detects persistent crashes it runs it in some different mode(?). And it looks like the app that I run from the IDE (MSVS2013) has received this "penalty". So it runs terribly slow even in release mode, let alone debug.
So I have a couple of questions to the community. First, have you ever observed such behaviour? Second, is the reason for slowdown indeed some system-wide information stored upon application crash? And finally, do you have an idea how to fix it?
Note: I could probably move the source folder to a different location, but it would require quite a lengthy rebuild step. Moreover, I'm just curious about what is going on. Also, system restart and full rebuild in the same folder didn't help.
Some context: the application uses Qt4 (also, Qt plugin system), MITK, ITK, VTK, CTK, OpenCASCADE, glew and related libraries all build from source on this machine.
Cheers,
Rostislav.
Pretty much a year after asking this question, and having the problem "self-resolve", I think I found the answer and decided to post it here in case someone would run into similar problem.
It seems to me that my application was put by the system into the fault-tolerant heap (FTH) after several crashes. Some more information on FTH can be found on MSDN. It might make sense to disable the FTH on the developer machine (at least temporarily) when debugging a particularly nasty crash.
The actual question: what are the differences between running in Visual C++ 2010 (both release and debug mode) and standalone, excluding anything that couldn't cause the problem stated at the bottom of this post?
I have a very specific problem with my program, so I am not going to post the code. If you would like to know details of the problem to gain some understanding, I post them at the bottom. Instead, I ask: what are the differences in running in visual c++ and standalone?
I am using Visual C++ 2010, and my program is using SFML 2.0. It runs fine in studio (I am calling it studio because it is easier to type), but when run standalone on some computers only a bug will occur within the program, to do with movement being delayed but other parts not. I cannot find any links between the computer specs of the users who test it and whether they work or not.
All dlls and such are included (at least, I think they are - the program runs fine, as detailed at the bottom - maybe some users have some framework installed?). On my computer, it works all the time in studio but not standalone. On my netbook, it works, on my older computer, it doesn't. The only project settings I changed with vc++ directories and linker settings.
Problem details:
All the sounds sound slightly different and there is a possible high pitched background noise. Character movement, enemy movement and space bar delay which is supposed to be 0.5 seconds is increased to about 5 seconds but "generating pixels" (an aspect in the game with the arrow keys isn't.
I'm stressing again that it only happens on SOME COMPUTERS, mine included, but always works when run within studio. A number of people have tested the game, and some reported the problem and others different.
[NOT THE MAIN POINT OF THE QUESTION BUT HERE IS AN EXTRA BIT: If you are so willing to help me that you wish to look through the entire source code, it's here: http://dl.dropbox.com/u/53835113/EVERYTHING.zip [note: ignore the massive amount of bugs and memory leaks other than the problem described :P]]
EDIT: THE POINT ISN'T THAT I WANT MY PROGRAM DEBUGGED! That is an optional extra. The question: what are the differences in running in visual c++ and standalone?
More edits: Found that the problem is due to the frame time not being correct. Not sure if this provides some insight.
Thanks to anyone who tries to help me!
GetFrameTime() in SFML was removed in a recent version because it returns the time since last frame rather than the time since last update. As a result, the it may return 0.
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