I am experiencing a very strange problem:
On HTC EVO 3D, sometimes, a looper does not call handleMessage after a message is sent to the looper's handler. It happens twice and very difficult to reproduce. The first time I caught it is after eight hours stress test. There was no errors and exceptions. However, I did not print out whether the message is successfully sent to the looper, but I am sure the looper thread is still alive and running through debugger.
I used the exactly same mechanism for more than half year and never had any problems. I am wondering does anyone meet the same problem? Is it the device issue?
Thanks,
Simon
Related
Going through the logs generated by my 'CoreBluetooth' state machine and have noticed on occasions a didDisconnectPeripheral is being called while the peripheral is in CBPeripheralStateConnecting and before a didConnectPeripheral. The code is immune to this strangeness however I would like to understand what is happening.
Anyone else experienced this or anything similar? I cannot find any logical explanation.
in iOS6 when CoreBluetooth was rather less mature I adopted the connection strategy of requesting a connection, if connection didn't result in the next 2 seconds, I would then call cancelPeripheralConnection and then issue another connectPeripheral this cycle would continue 3 further times before terminating and informing the user that something is wrong.
It would appear that the calls to didDisconnectPeripheral, even when not first connected, were a result of the intermediate calls to cancelPeripheralConnection.
Now with the stability of iOS7 and having learned that connectPeripheral never times out I have removed the complexity of intermediate cancelPeripheralConnection & connectPeripheral calls and just wait for the connection, with a timeout.
No more mystery didDisconnectPeripheral calls!
I am working on an application in Silverlight 5. We use WCF for all of our network communication, and it mostly works well. However, we have a couple of Virtual Machines that we use for testing where the app fails, tries to restart itself, fails, etc. in an endless loop. I have added a lot of tracing code, and a lot of try catches, and I have it isolated all the way down to the line of code that is failing, but I still can't get an actual error message from the failure, just the crash. Originally, it was failing on this line of WCF code:
return await Task<List<Instance>.Factory.FromAsync(Channel.BeginGetInstance, Channel.EndGetInstance, null);
In case it had something to do with the use of async/await, I went back to our old code with callbacks. I still get the same failure, but now I can see the call to the WCF function completes successfully, but the log statement on the first line of the callback never happens, so it seems like its dying before or outside of the callback.
One other note, it appears the code we have in Application_UnhandledException is not firing, but the code in Application_Exit does run, I see that as the last line in the log file.
I tried to setup remote debugging, but I am unable to connect to the app before it crashes and recycles, so that didn't help either.
I also used TCPView to watch the network traffic, and it looks like communication is happening in both directions.
If anyone has any suggestions of anything else to try, I would greatly appreciate it.
I spent 10 days chasing my tail on this before finally realizing my problem. There was a bug in the error logging code. It was generating an error, I was just not seeing it. Once I realized that and got the error message, the actual underlying bug was fixed in about 5 minutes. Good lesson though, never assume the underlying code is working, no matter how simple it is.
I'm working on a console app developed by a guy who doesn't work here any longer. While debugging, the ContextSwitchDeadlock exception was thrown (I found this question on the exception). If I ignore it, the app will eventually work through the loop it occurs in. The app runs as a scheduled task every day, but this particular process is not called every single time.
I'm wondering if it is OK to allow this exception to go to production. The author of this app put it in production with this exception, and its been running ever since. Should I just make my (unrelated to this exception) updates and leave the app as is? Or should I try to address the issue? Addressing it seems daunting to me :/
Ben. I would say 'NO'. Unless your exception is a ThreadAbortException (i.e. the user closed a window and so the process is dead) or some such thing, an exception like this could open your code up to cascading failures. Based on what we do where I work:
I think, as a band aid, you should encapsulate the offending code with a Try-Catch, and wire it up to send you an email every time it Catches so you have documentation on what's going on AND so that you prevent cascading failures from propagating throughout your code (quarantine the problem).
Towards a fix (when you have time), debug it and step through to figure out why your main thread is taking so long, and if you can, create a worker thread to handle that (DISCLAIMER: this would be my opening attack angle at this problem, based on the answer from the link you provided. I have NOT tested this, nor do I have experience enough to definitively say this will work).
EDIT: After running into this error for a particularly long running process myself, I came across this slew of answers on msdn:
http://social.msdn.microsoft.com/Forums/en/vsto/thread/bf71a6a8-2a6a-4c0a-ab7b-effb09451a89
While I resolved my error (I was reading a System.IO.FileStream into a String Builder instead of using a String and the StreamReader ReadToEnd method), I think it might be helpful to you.
I have client server application using distributed object. some time my code is working fine but some times i am getting
*** NSDistantObject initWithCoder: 7 not given away for conn 0x100124c60 error. and some times my application receiving SIGARRT.
Program received signal: “SIGABRT”.
sharedlibrary apply-load-rules all
Data Formatters temporarily unavailable, will re-try after a 'continue'. (Not safe to call dlopen at this time.)
saw it several times in iOS programming. It was always that I was running out of memory. for leaking or infinitive recursion.
see this: Data Formatters temporarily unavailable, will re-try after a 'continue' or Data Formatters temporarily unavailable, will re-try after a 'continue'
"Data Formatters temporarily unavailable, will re-try after a 'continue'." means that something has gone so horribly wrong in your code that even the debugger bailed. As dragyn said, this usually involves some form of rapid object creation or recursion calling. Add a few NSLog lines into your code to help you see how far your code is getting and where it might be looping/calling itself.
from: http://www.cocos2d-iphone.org/forum/topic/7314
Scenario:
I have a Distributed-objects-based IPC between a mac application and a launchd daemon (written with Foundation classes). Since I had issues before regarding asynchronous messaging (e.g. I have a registerClient: on the server's root object and whenever there's an event the server's root object notifies / calls a method in the client's proxy object), I did long-polling which meant that the client "harvests" lists of events / notifications from the daemon. This "harvest" is done through a server object method call, which then returns an NSArray instance.
It works pretty well, until for a few seconds, the server object's process (launched thru launchd) starts being labeled red with the "(Not responding)" tag beside it (inside Activity Monitor). Like I said, functionally, it works well, but we just want to get rid of this "Not responding" label.
How can I prevent this "Not responding" tag?
FYI, I already did launchd-based processes before and this is the first time I did long-polling. Also, I tried NSSocketPortNameServer-based connections and also NSSocketPort-based ones. They didn't have this problem. Locking wasn't also an issue 'coz the locks used were only NSCondition's and we logged and debugged the program and it seems like the only locking "issue" is on the harvesting part, which actually, functionally works. Also, client-process is written in PyObjC while server process was written using ObjC.
Thanks in advance.
Sample the process to find out what it's doing or waiting on.
Peter's correct in the approach, though you may be able to figure it out through simple inspection. "Not responding" means that you're not processing events on your event queue for at least 5 seconds (used to be 2 seconds, but they upped it in 10.4). For a UI process, this would create a spinning wait cursor, but for a non-UI process, you're not seeing the effects as easily.
If this is a runloop-based program, it means you're probably doing something with a blocking (synchronous) operation that should be done with the run loop and a callback (async). Alternately, you need a second thread to process your blocking operations so your mainthread can continue to respond to events.
My problem was actually the call for getting a process's PID using the signature FNDR... that part caused the "Not responding" error and it never was the locks or the long-polling part. Sorry about this guys. But thank God I already found the answer.