I am having an odd problem. There is a large request I am debugging so I threw a cfabort in at a particular spot before some processing is to occur. It doesn't appear to be working as the request keeps running in browser and shows up in the CF monitor, where I kill it manually. Throwing an error immediately works, though doing a cfabort with "showerror" doesn't. Any thoughts on what is going on?
Well, I found the culprit. I had debugging on and set to send output to ColdFire. I guess there was a massive amount of data related to the queries and that was still being created when I called cfabort, but ignored when throwing an error. I know I've run into this before so I guess now I have a place to find the answer again :-)
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 a C++ program that needs to ping a device before it proceeds. I've been using IcmpSendEcho for a few months now. During this time I have seen my program hang on the IcmpCreateFile call more than once. I haven't pinpointed the cause and all of my searches lead to nothing, this seems to happen for no rhyme or reason, whether my program is running for weeks or was just launched.
HANDLE hIcmpFile;
hIcmpFile = IcmpCreateFile();
Is anyone familiar with this, or should I just use a different method to ping?
EDIT: I'm not 100% sure but windows update seems to encourage this behavior; I don't seem to see this issue when a server or the client it's talking to have update turned off.
I wrote a C++ server/client pair using C++11, boost::asio and HDF5. The server was running fine for a some time (2 days), and then it stopped with code 137. Since I executed the server with an infinite loop, it was restarted.
Unfortunately, my error logs don't provide sufficient information to understand the problem. So I've been trying to understand what this code means. It seems there's consensus that this means it's an error of 128+9, with 9 meaning that the program was killed with kill -9. Now I'm not sure at all why this happened. I need help to find out.
By reading further, I found out that it could have been killed by the system because it exceeded a certain allowed execution time, and thus the system killed it. Now this is not so unlikely, since my linux server is provided by my university, so they could be applying some kind of security to do this. I read about something called timeout in linux. My first question is: How can I know if this is the cause of the problem?
My second question is: what should I check also to understand this problem? What would you do? Please advise.
If you require any additional information, please ask.
Thanks.
Sounds like you have blown through memory limits and your linux memory manager sent SIGKILL to your process. In that case you should check /var/log/messages file to see if there is anything about it. That's the first thing I would do. Check with your sysadmin if you don't have permissions.
The bug I'm seeing is intermittent.
First, the codebase.
The repo is here
Where I think the bug is coming from is here
I think GetQueuedCompletionStatus() gets blocked because of thread synch issues?
Debugging the code, I made a screenshot of it, you can see the network tab showing one file having the stalled status.
It's not always one file stalling, that's just one case. Other cases, one another file would stall.
What should I be thinking of here? Should I be adding mutexes in there?
I was getting the same error intermittently when trying to start debugging,
below are the things I have done
Firstly, cleared the cache, cookies, etc from the browser. The issue was still there.
Then I noticed that my system was running with very low disc space, So removed unnecessary stuff, emptied the recycle bin, etc. Even this had not fixed the issue
Finally, as I had not shut down the system for more than a week, I have shut it down completely and restarted. And the issue has been resolved.
I am trying to figure out a "Failed to resume in time" problem. In one of our testers devices (which is an iPhone 4S with the latest OS) it happens very frequently, whereas in my own device it doesn't seem to happen at all.
Anyway, I got a few crashlogs. I am unable to trace the root of the cause though. I understand that the issue might be
1.When a process is holding up the main thread for too long.
2.When there is a memory issue.
I don't think the memory is much of an issue since it seems to happen when the user leaves the main menu and comes back. Nothing much is happening in the main menu so it probably is a task that runs too long.
Here is an excerpt from the crash log:
Can somebody help me or guide me on who I can trace the cause of the issue? Is there anyway to turn off the watchdog timer(probably not huh?) Also, what does highlighted thread refer to?
I have already checked my applicationDidBecomeActive & applicationWillEnterForeground to make sure there is nothing going on there.
To my knowledge there are no synchronous calls being made at this point. Does Reachability use synchronous calls to check for internet? How can I check for that?
I am not making any large data transfers upon resume.
I notice that GameCenter automatically logs in or check for log in upon resuming your app. Is there anyway to prevent this? Could this possibly cause a time out issue?
I tried doing a time profile, but I am not able to understand how to use it to analyze. If you can provide a good resource for that, that would be amazing.
Thanks!!!
You're currently in "trying to find the issue mode". You should switch to "try to find out how much of an issue this really is" mode.
So go find another 4S (actually as many as you can) to rule out that it's a device-specific issue. If it happens on all 4S it should be easier to pinpoint. If not, have someone else look over it, discuss possible causes. The peer programming approach often helps when you're stuck in a dead-end situation.
If the issue is only on that one device, you might want to check if it's broken (or "jailbroken") or might simply need a hard reboot (hold power and home for 10+ seconds).
If it only happens on some devices but not all, try to find what they have in common. This could be language/locale, or dictation, practically any kind of setting the user might have changed. If necessary, write a logger that logs as many settings as possible to your (web) server so you can compare settings one-by-one and quickly discard those that aren't in synch.
If only very few devices are affected, you could also ignore the issue and hope that additional crash logs from users will reveal the key to the issue.
Finally, there's always the option to disable suspend on terminate and instead terminate the app when the home button is pressed (as it was pre iOS 4). Unless of course the app has to run in background.