incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Grieve (JIRA)" <>
Subject [jira] [Commented] (CB-1404) EXC_BAD_ACCESS when using XHR bridge mode
Date Mon, 10 Sep 2012 19:28:07 GMT


Andrew Grieve commented on CB-1404:

Just tried for a while to repro this using the exec() benchmark in the mobile-spec tests.
No success.

Tom - did this happen for you in debug more or just release mode? when the device was attached
to Xcode?

Is the handleOpenUrlInternal:self part in your example relevant?

For now - I think I'll just change the default mode to XHR_NO_PAYLOAD, but I'd like to keep
looking at this and figure out what's going on. The payload is passed via a header of the
XHR, and the XHR is never aborted, so it's weird that it works without a payload. Perhaps
we could use query params instead, or just lower the threshold of how much data to send. I
need to be able to repro it first though :(.

I'm running 5.0.1 on my iPad 2, so I'll update to 5.1.1 and see if it makes a difference.
> EXC_BAD_ACCESS when using XHR bridge mode
> -----------------------------------------
>                 Key: CB-1404
>                 URL:
>             Project: Apache Cordova
>          Issue Type: Bug
>          Components: iOS
>    Affects Versions: 2.1.0
>         Environment: iPad 2, iOS 5.1.1
>            Reporter: Tom Clarkson
>            Assignee: Andrew Grieve
> When calling a plugin the app crashes on WebThread with EXC_BAD_ACCESS in WebCore::DocumentThreadableLoader::cancel.
> This appears to be some sort of timing issue, as it does not happen on every call - I
am seeing it in an autosave function which makes lots of calls to PGSQLitePlugin. 
> The error did not appear before upgrading to 2.1, and setting the bridge mode to IFRAME_NAV
restores the previous behaviour (no crashes, but odd scrolling functionality).
> Setting the bridge mode to XHR_NO_PAYLOAD also seems to fix it - not sure if removing
the payload actually does anything different or just makes it fast enough that the timing
condition does not come up in normal app usage.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

View raw message