Another EXC_BAD_ACCESS

[Djohannot]

Hi,

First of all, thanks for your work, very usefull!

Like i've seen on this forum, i'm not the only one who meet this
error....

I execute a Synchronous request (yes, i want to do it synchronously, i
need to block the user till the answer). The request is executed
without any problem and the next view is open, but on the next view
when i type text inside a textfield i've an EXC_BAD_ACCESS thrown
without any help. I've try the Zombie attribut, no informations too.

I know it comes from ASIHTTPREQUEST, because if i remove the request,
everything goes fine.

I've look at your code and the problem seems to come from the
'startRequest' method (if i comment it, my code can continue). Do you
modify a system variable inside of it? my feeling tell me it comes
perhaps from the "CFRunLoopRun" (l.1043 from ASIHTTPREQUEST.m),
possible?

I really need your help, thanks a lot,
regards,

David J.

[Djohannot]

I continue to look at your code :) i'm now inside the startRequest
method from the ASIHTTPREQUEST class.

I've seen that your statusTimer retainCount is at 3 when i execute the
request, normal?

If i comment the end of the method:

[self setStatusTimer:[NSTimer scheduledTimerWithTimeInterval:0.25
target:self selector:@selector(updateStatus:) userInfo:nil
repeats:YES]];
//NSLog(@"StatusTimer: %d",[self.statusTimer retainCount]);

// If we're running asynchronously on the main thread, the runloop
will already be running and we can return control
/*
if (![NSThread isMainThread] || [self isSynchronous]) {
while (!complete) {
CFRunLoopRun();
}
}
*/

then the request is no more executed but I've no more EXC_BAD_ACCESS.
so, where come this BAD_ACCESS from??? any idea?
i've update my source with the one of the 6 january (on your website,
it's wroten from 2009, isn't it from 2010?) but nothing changed.

Please...... i pay you a beer if you find the error :)

David J.

[AlanD]

David,

I would almost guarantee you that what's happening is that the object
you set as the delegate has fallen out of scope before the request
completes...

The error you're seeing most often comes up when something makes a
call to a pointer that is released and not set to nil. When you
comment out the calls that actually make the HTTP request, it returns
immediately, and never calls your delegate.

I hope this helps you narrow it down further...

-=Alan

[Ben Copsey]

Hi David

> I continue to look at your code :) i'm now inside the startRequest
> method from the ASIHTTPREQUEST class.
>
> I've seen that your statusTimer retainCount is at 3 when i execute the
> request, normal?
>
> If i comment the end of the method:
>
> [self setStatusTimer:[NSTimer scheduledTimerWithTimeInterval:0.25
> target:self selector:@selector(updateStatus:) userInfo:nil
> repeats:YES]];
> //NSLog(@"StatusTimer: %d",[self.statusTimer retainCount]);
>
> // If we're running asynchronously on the main thread, the runloop
> will already be running and we can return control
> /*
> if (![NSThread isMainThread] || [self isSynchronous]) {
> while (!complete) {
> CFRunLoopRun();
> }
> }
> */
>
> then the request is no more executed but I've no more EXC_BAD_ACCESS.
> so, where come this BAD_ACCESS from??? any idea?

Hmm, I think you might be on to something with the status timer, it looks like it fires once after a synchronous request completes, which I guess might cause problems if progress delegates are dealloced.

I'll need to think about this a bit more. If you set all your request's delegates (delegate, uploadProgressDelegate, downloadProgressDelegate) to nil once the request is complete, does the problem go away?

> i've update my source with the one of the 6 january (on your website,
> it's wroten from 2009, isn't it from 2010?) but nothing changed.

Whoops, right you are. Fixed now. :)

Best

Ben

[Djohannot]

Hi guys, thanks for your answer.

@AlanD:
you're write, the EXC_BAD_ACCESS appear for null pointer.
I've try tools like instruments (for the leaks) and clang (very
usefull for a static leaks analyze)
with no result. I've try the NSZombieEnabled, always no result...

@Ben:
Like you said Ben, i think it's due to a timer problem, but i don't
know how to fix him.

I explain better the problem.

I use a tabBar with 4 subviews. when i click on the second tab, the
view load and the method viewDidAppear execute a synchronous request.
The request is execute correctly but the following view will in all
case crash (i've try to load another view and same problem appear).
The funny
things is that it will only crash when you type text in a textfield :)

to remove the problem, I've modify my logic and the request is no more
send during the viewDidAppear but with a button.
This solution goes in the way of Ben's theory:
a delegate is release and the event throw the EXC_BAD_ACCESS.

In all case, this problem will continue to appear, and i'm pretty sure
that the majority of the EXC_BAD_ACCESS describe
on this forum are based on this problem. it could be interesting to
have a look at this issue.

In all case, it's a create library Ben that i council to everyone who
want to spare time for REST communication ;)

David Johannot

[Ben Copsey]

Hi David

> Hi guys, thanks for your answer.
>
> @AlanD:
> you're write, the EXC_BAD_ACCESS appear for null pointer.
> I've try tools like instruments (for the leaks) and clang (very
> usefull for a static leaks analyze)
> with no result. I've try the NSZombieEnabled, always no result...
>
> @Ben:
> Like you said Ben, i think it's due to a timer problem, but i don't
> know how to fix him.
>
> I explain better the problem.
>
> I use a tabBar with 4 subviews. when i click on the second tab, the
> view load and the method viewDidAppear execute a synchronous request.
> The request is execute correctly but the following view will in all
> case crash (i've try to load another view and same problem appear).
> The funny
> things is that it will only crash when you type text in a textfield :)
>
> to remove the problem, I've modify my logic and the request is no more
> send during the viewDidAppear but with a button.
> This solution goes in the way of Ben's theory:
> a delegate is release and the event throw the EXC_BAD_ACCESS.
>
> In all case, this problem will continue to appear, and i'm pretty sure
> that the majority of the EXC_BAD_ACCESS describe
> on this forum are based on this problem. it could be interesting to
> have a look at this issue.

Yes, dealloced delegates do seem to be something that lots of people struggle with, but generally they just need to modify their design to fix the problem.

Having said that, it does look like there might be a problem here, the timer method shouldn't be attempting to talk to delegates after a synchronous request is finished. Will investigate this weekend.

Best

Ben