For various reasons I need to use HttpWebRequest instead of the built-in WWW class to call out to web services in our Unity project. I'm finding that Request.EndGetResponse hangs under certain circumstances. The issue is exacerbated when the debugger is attached--it does happen from time to time without the debugger, but happens close to 100% of the time when the debugger is attached. It is only happening when I'm calling a web service using HTTPS.
I plugged in Wireshark to look at the two traces. Oddly, the trace when the debugger is attached includes a "Handshake Failure" where the trace without the debugger does not. The other interesting thing is that the trace that works includes two [FIN, ACK] messages presumably from other failed attempts.
Ultimately I think I'm running into some known issues with the Mono 2.6 threadpool. That said, I don't understand what EndGetResponse is doing that could cause it to hang--I thought this was a synchronous operation. I also don't understand how attaching the debugger could affect the issue.
If there are any mono experts out there, I'd appreciate any insight!
Related
Apologies, this may not be a good question.
I have a VB based UI application running, supported by C++ modules through COM.
a month before it started to close randomly without any clue. I initially analyzed in perspective of a application crash and expected to see Dumps and Application/System event log entries. I have prior experience in application crash debugging. tried registry configurations (Like, CorporarteWerServer for application hang, LocalDumps and all that).
But no luck.
End user says they don't see any popup like "This application is not responding with options close/wait". The application just closes down without any prompts.
We have logging enabled where we intentionally close the application using exit(). So it is not closing formally.
User does not have testing environment where we can install debugging tools and monitor.
I have verified for insufficient memory and antivirus software and they are fine.
So, Is there any cases where an application can just simply close/crash without any prompts, logs, dumps ?
Please suggest if I am missing something. Also, is there any built-in windows tools to monitor ?
My SL application is commercial and working just fine on hundreds of machines.
SL is using a WCF service and it works as expected, but today I observed behavior on client machine, where literally no call is made to server.
After you click button that sends a call, some error occures, and no record about WCF call is created in Fiddler.
Error is:
[HttpWebRequest_WebException_RemoteServer]
Arguments: NotFound
Debugging resource strings are unavailable...
I read about this error that people recommend to use Fiddler, but as I say there is no call displayed in Fiddler
So problem is worse than I thought initially.
It comes and goes. Currently we have found a working solution that fixes the problem after it appears although it doesn't make any sense to me.
For example if I get this error in chrome & mozilla & OOB version,
launching a program in IE works, and after that chrome,mozilla & OOB
start to work too.
Thing is that same people who had this problem solved with this workaround experience it again in some days, like a week, with no apparent reason, and then combination of launches from various locations helps (usually IE helps the most).
Any help appreciated, I start a bounty as its pretty sick bug and I need to fix it somehow.
Update
Weird IE fix scenario:
At some point OOB version gets into state where it doesn't send any WCF request to server.
(fiddler doesn't see it, server doesn't gets it).
After launching web version in IE, and hitting the same button, that sends WCF request we get desired result in IE web version.
Without changing anything else, just relaunching OOB version which was in this buggest state before, makes OOB version work correctly. Its not reinstalled, not changed - nothing.
This is what I call "IE cure" of this problem.
So the question is what can IE launch potentiall change for OOB version?
According to this thread the message Debugging resources are unavailable appears when de client is not using the the Silverlight Developer Runtime.
This means that the actual exception is hidden from you (and us) so the next step is to reproduce the error on a system that has the Silverlight Developer Runtime.
I found this article. It might be worth it to check the certificate you are using (are you using a certificate) It is one of those things that is different with OOB apps and browsers.
My problem is, that I am running a webapp on Tomcat7 on a 2GB 2Core VPS and when the app crashes with heapoverflow exception Tomcat doesn't start or stop. When I try to access it via the browser it just hangs.
If I try to stop it looks like it stops but if I do it repeatedly it is supposed to throw an exception because it's already stopped, but this is not the case. Only after 15 minutes am I able to start it up again.
I know that I should solve the heapoverflow problem, but the thing is I am simply not able as the framework I am using turned out to be nod thread safe and I have to create a new instance of a memory heavy object for every request :( I tried to come round the problem by adding some basic controller which only allows certain amount of objects to be created and the rest of the request are redirected to a Sorry-page. Since it is for a UNI project and the main goal is not being able to serve hundreds of users it's not important to make the framework thread safe.
Still I need to know why Tomcat does it after it crashes. Also it would help if you would have a better idea how to limit the number of these objects being in the memory at the same time.
++++++++++
At the moment the only solution I can see is to get say 2GB of more RAM so I will be able to serve some 15-20 users at a time.
Generally after tomcat crashes with out of memory error it is in unusable state and the process has to be killed either manually or by using
catalina.sh stop -force
For a discussion on how to prevent those out of memory errors see
Dealing with "java.lang.OutOfMemoryError: PermGen space" error
Though ultimately you may need to throw more hardware at the problem.
This might also come handy:
Can I auto restart tomcat jvm on out of memory exception
I have an application which works with sockets and reads / writes data. It uses Foundation framework combined with CFNetwork and stdio.
Here is the issue - when it is launched from console (bash shell) it works 100% fine and there is nothing wrong with. However when it is invoked by another application via NSTask madness begins. The whole application goes insane and it only reads the socket once and then hangs up (it is meant to exit after it is done).
This application does not rely on environmental variables or any other things like that. It is not a user issue either. When it is launched it sends a simple request to the server and 'printf's the response and reads again. This happens untill a termination packet is recieved.
I am really confused, and it feels like there is something inside the framework which makes the app insane just to piss the programmer off.
By the way, I'm on Mac OS X Snow Leopard and the application is for the same platform.
EDIT 1 : Redirecting stdout to an NSPipe causes it. But why ?
libc treats a pipe/file and a console connected to a (pseudo) terminal differently. In particular, the default buffering policy is different. See the extensive discussion in this Stack Overflow Q&A.
So, it's perfectly conceivable that a program which works when connected to a (pseudo) terminal won't work with a pipe. If you need more specific advice, you need to post (at least the skeleton of) your code.
What exactly happens when we do IISreset? What resources get released? We have an ASP.Net website (.net 1.1) which use Crystal reports 11. Lately, running reports are throwing several crystal report specific exceptions and then the users can't run reports anymore. Resetting IIS lets the users log back in and run the reports until it fails the next time. Knowing exactly what resources are released when IIS is reset will help us dig deeper to find the root cause. Any help?
Pretty much everything. All thread pools, asp, asp.net, shared memory, etc... will all be purged. Doing in IISReset is basically the same as going to Services->WWW Service->Restart. Also, it will affect SMTP and FTP if you are running these services as well.
To narrow your problem down slightly ( and to reduce impact ), you should try putting your website in its own App Pool. Then when it next hangs, see if restarting the app pool fixes the problem. Then you are limiting things to just one running web application, not completely taking down iis. If the problem persists and still requires an IISReset, you at least have one more datapoint to work with.
EDIT: In response to your additional comment, I would suggest you do as much logging as possible and see if the problem becomes obvious. http://learn.iis.net/page.aspx/579/advanced-logging-for-iis-70---custom-logging/
Obviously, a quick run through Event Viewer is probably a good idea.