iPad development, iOS 4.3, objective-c, xcode 4.1.
I have created a wrapper class, which is used to call a method on a web service. It works fine when I make the first call, but fails on subsequent calls.
A method in my class, "runMethod::", opens a NSURLConnection and does the call asynchronously, with the wrapper class itself as the NSURLConnection delegate.
I have read somewhere that there's a fault with Android, which keeps a pool of connections. When you try to make a connection a second time it fails because the previous connection has been kept open, despite the code closing it. Hence, I suspect the problem is that the connection remains in the pool, and when I try to make another one it clashes? Maybe xcode has a similar issue?
And the symptoms of the failure are a seemingly random 'bad access' on a random line in one of the delegate selectors, which suggests this has something to do with threading - I understand that HTTP connections operate on their own thread.
I can provide the full wrapper class if need be, but anyone any ideas?
A 'bad access' error simply indicates that you're dereferencing an invalid pointer. This is most often due to improper memory management, such as failing to retain some object. Code would help, but first try the Analyze command in Xcode -- the static analyzer is pretty good at finding memory problems.
Related
I have weird issue running the last version of Raknet on iOS with Unity3D: I get CONNECTION_ATTEMPT_FAILED when trying to connect to the server.
Now let's me detail the issue:
he exact same Library connects fine when used in an ObjectiveC application, so the issue seems to be Unity3D related.
I already managed to pinpoint my issue to be located in Raknet reliability layer:
Apparently, during the last step of the connection process (when the connection handshake as been completed) the reliability layer of the server thinks that the ID_CONNECTION_REQUEST packet received from the client is an acknowledgment instead of a message. Therefore it doesn't answer. Ultimately after a few tries, (and a 10s timeout) the client fails with the CONNECTION_ATTEMPT_FAILED error.
Does anybody there as an idea? I will update the question when I manage to get more info.
Update
We are using Unity3D 5.1.1f1
We managed to find a workaround! See answer for more information. As the workaround doesn't tell us much about what really happened, I would gladly hear some C++/XCode/Unity/iOS/AppleLLVM6.1 experts around here explain what really happened.
The issue was that the Raknet header wasn't properly generated by the iOS client. Namely we were sending ACK messages in place of simple packets. The rest of the message was considered as garbage by the server and the packet was dropped. The client kept trying to send the corrupted handshake packet a few times before timeouting.
This doesn't tell us why, doesn't it? Apparently the serialize method of the class DatagramHeaderFormat wasn't called as it should have been when running Raknet in Unity (iOS). Something else (and I don't know what) was linked in place of this method and was filling the BitStream with a corrupted header.
I am quite sure that the serialize method wasn't called because printf calls from inside weren't displayed in the console.
We renamed DatagramHeaderFormat::serialize into DatagramHeaderFormat::serializeHeader and... voila, it works.
Now I only want to understand what did the compiler (and why).
I'm using MKNetworkkit to parse XML data to the server. Before Entering into the success block its gets crash with EXC_BAD_ACCESS with out any reason and am already done with NSZombieEnabled like all the stuffs.![Below is the screen shot of where its getting crash.][1][1]: http://i.stack.imgur.com/FL3l9.png
You may find this useful to help debug http://subhb.org/2012/07/02/how-to-debug-exc_bad_access-error/
You will get EXC_BAD_ACCESS error mostly in the following scenarios:
You are trying to access an object that is not initialized.
You are trying to access an object that no longer exists. Either it’s being released or it’s nil. In ARC mode, make sure you take
ownership of the object that you want to use.
You are passing an message to an object that the object doesn’t understand. It can also happen for bad typecast.
Have you tried running breakpoints on your code and stepping through your program line by line and seeing if any of the above match the result?
my application uses two self-written components that perform actions during the "loaded" procedure.
The component created first is an single-instance control that should exit the application when another instance is found.
The component created secondly is my database access that establishes the database connection in the "loaded" procedure.
I try to end the application before anything else happens, if a first instance has been found.
Tryout 1:
In my instance control, i call "Application.Terminate" to stop my application. That does not work - my database connection still gets established. Seems that "Application.Terminate" uses a "PostMessage" call to itself, which won't get read until the message gets received (which will happen after all components are loaded...). So obviously, this solution does not work for me.
Tryout 2:
In my instance control, i call "Halt" to stop my application. This immediately stops my application, but seems to create a load of memory leaks - at least that's what delphi's "ReportMemoryLeaksOnShutdown" tells me. Afterwards, i get this annoying "This application has stopped working" windows dialogue. This solution does not work for me.
Question A:
Is there another way to end an Application?
Question B:
Does Delphi's memory leak report work correctly when using "Halt"? Are there really memory leaks after exiting the Application with "Halt"?
If Application.Terminate terminates too late, and you want to terminate post haste, then Halt seems to me to be the appropriate course of action. I don't particularly see why Halt should lead to This application has stopped working exceptions. That suggests that your program's unit finalization code is raising exceptions which are not handled. You could perhaps try to work out (using the debugger, say) why these exceptions are raised and protect against it. Or you could avoid unit finalization with a call to the even more brutal ExitProcess.
There will indeed be memory leaks when you call Halt. However, these can safely be ignored because the operating system reclaims all allocated memory when a process terminates. In other words, the memory is leaked in the sense that is not freed by the application, but the operating system frees it immediately in any case.
However, whether or not a brutal Halt is the correct course of action for you, I cannot say. That's for you to decide. FWIW, a call to Halt from inside a component's Loaded method sounds exceptionally dubious to me.
If all you want to do is ensure that just a single instance of your program runs, then you can make simple modifications to the .dpr file to achieve that. That subject has been covered over and over again here on Stack Overflow. You'll find good coverage and advice in Rob Kennedy's answer here: How can I tell if another instance of my program is already running?
I have the following crash log and code to go along with it:
https://gist.github.com/emilevictor/7422ac293eb27b415fb8
I'm a bit confused, as I have wrapped this Core Data code (which creates a new instance in the database) with a try catch block but it is still crashing out occasionally in on release compiled code.
This is on a device which has had its local data wiped and installed from scratch, by the way.
I'm not sure what else to do, I assume that this code might have an issue.
First the try/catch problem. #try/#catch only trap NSExceptions which have been #thrown or -raised. You don't have this kind of exception, you have a segfault. These happen at a much lower level and cannot be trapped in a #try/#catch.
The real problem here is what's going wrong to cause the segfault. Usually this is caused be objects which have been prematurely -dealloced or by notifications being sent to -dealloced observers. I can see from your call stack that the process is in the middle of sending a notification, so my guess it the second type.
Somewhere, you have registered an observer and that observer has gone out of scope (-dealloced) without unregistering itself. I would start by profiling the app for zombies.
I have not been able to find a way to cancel/terminate asynchronous read operation after successful HttpWebRequest. There is no way to set timeout, ThreadPool.RegisterWaitForSingleObject is not working too. And closing the underlying socket is not an option too because neither HttpWebRequest/Reponse provide access to it.
Edit:
Sadly this approach that Sunny suggestet works only for HttpWebRequest.BeginGetResponse. For the stream that you get after GetResponseStream() for some reason RegisterWaitForSingleObject is not working - the callback is never called.
The situation is the following:
I got an application that uses HttpGetRequest. It is build by using the default MSDN example for async httpwebrequest. Getting response is working like a charm. But on rare occasions the server that my httpwebrequest is connecting to forgets to close the socket. So I am hung on a infinite read from BeginRead.
In some rare occasions the other server forget
Why not RegisterWaitForSingleObject? You can use it for time out, and in the handler you can call request.Abort().
Here's an example. Btw, I have used simial approach before I found this article in the past, and it worked like a charm.
NOTE: The real end of the operation will happen on the next Stream.Read (of only the request/response was async) or Stream.EndRead (if the reading is async as well). You still need to capture the exception thrown in the EndXXXX handler.
EDIT: If the RegisterWaitForSingleObject never get called, then you have another issue, which is most probably a ThreadPool having not enough free threads. The callback for RegisterWaitForSingle object is called on a ThreadPool thread, and if there is no a free thread in the pool, it will never get called. You have some solutions:
Make your pages asynchronous. Why? How.
Change the max threads in the pool.
In any case, increasing the pool size will not help you too much. You have to inspect your code for resource (stream) leaks, and make sure that you not only call request.Abort(), but also close the response. Make sure than in your callbacks you use the proper EndXXX method, etc.
I nazdrave :)