Closed audungk closed 6 years ago
Intriguing. This is a fire-and-forget message, so it shouldn't be waiting for anything…
Can you look that the threads running at the time of the pause, and verify that there's another thread waiting in CFRunLoopRun(), with AQXMLParser code on the stack? This call is used to notify the waiting runloop on another thread that it should call the stream's delegate event handler.
This is an image of the threads running at the time of the pause:
http://skitch.com/audungk/rsigt/screen-shot-2011-03-25-at-16.28.37
The only AQXMLParser code is in the same thread...
Can you expand that thread & re-post for me? Drag the slider at the bottom of the thread view all the way to the right.
See enclosed image:
http://skitch.com/audungk/rsiqt/screen-shot-2011-03-25-at-17.02.29
It could be related to buffer size, as it stops at the same location in the xml on most tests. Around 1 in 10 tries ends with a NSXMLParserErrorDomain error 5, and thus ends the parser, but most tries keeps the parser running in the background.
Another theory might be related to overreleasing, as the xml-source contains xml inside cdata elements, and thus needs a parser inside the parser... But, as you might understand, I'm rather stuck at the moment, and extremely grateful for all your help!
While running AQXMLParserWithTimeout in a dispatch_async() block, AQGzipInputStream pause on line number 261:
kern_return_t kr = mach_msg( (mach_msg_header_t *) &msg, MACH_SEND_MSG, msg.header.msgh_size, 0, MACH_PORT_NULL, 0, MACH_PORT_NULL );
The stream is never closed, and the parser is waiting for input for an indefinite period