URLLoader hangs whole app for no apparent or catchable reason on OSX 10.8.2, Air 3.5

Question

I've got a HTML/JS air app which connects to a REST interface on a remote server via HTTPS. It POSTs data to the interface every minute, sometimes more frequently but certainly no more than 3 times a minute.
Every time it connects, my code creates a URLRequest, a URLLoader, sets up some listeners on the loader, then sends the request. It's literally a textbook piece of code, lifted almost verbatim from Adobe's own examples and has worked for a year on OSX and Windows without any problems.
A couple of weeks ago my Macbook Air updated itself to 10.8.2. I think by coincidence it also updated to the latest Air 3.5 at roughly the same time.
As of that update, my app has begun to hang at random, but always as a result of URLLoader.load(). It can't be fixed except by Force Quit-ing and restarting. I've added trace and try/catch statements around literally every line of my interface code, but the answer is the same: it gets as far as the URLLoader.load() statement, then hangs.
Nothing is caught by my error event listeners
Nothing gets caught by my try/catch
Nothing can be seen to have caused it in the OSX Console (besides the generation of the hang report).
Nothing can be seen in the logs on the webserver providing the REST interface, except standard 200 requests being returned without fail, until the point of hang.
I've tried
Updating to the Air framework 3.6 beta
Updating my SDK to the latest version and rebuilding the app
Running the app in ADL debugger or "properly" after installation
Nothing makes any difference. If I comment out the URLLoader.load() line, the app runs fine, indefinitely.
Can anyone shed some light on this?

Answer 1

The timing of some recent crashes indicates a possible connection between Air and overall system load.
This morning my app crashed within a minute of launching - the first time it has been so soon. In fact it was the very first sync with the API that the app performed, which crashed. However my personal routine had also changed and it seems more than coincidence. The crash occured around the point that I launched Google Chrome complete with about 20 remembered tabs. Usually my app launches (on startup) several minutes before I run Chrome for the first time.
Whether the "load" I refer to is specific to what Chrome was doing (launching all those tabs), or merely to do with what the system was doing to launch a high CPU program in general, is another question. It isn't the first time I've noted a coincidental link between the app crashing and the amount of tabs i've had open in Chrome, but this is the first time it felt like a causal link.