Axant Tech Blog

Flash and Mac OS X bug while interrupting connections

Sunday, March 1st, 2009 | Web

Some days ago, testing an upload feature in a web application we’re working on, someone pointed out that something seemed to go wrong trying to interrupt an upload using Firefox on Mac OS X 10.5. That sounded quite strange, since that feature worked well on Windows and Linux on Firefox, Safari and Internet Explorer too.

To manage multimedia content uploads, we use a Flash-based plugin called SWFUpload: the main reason is to allow multiple files selection and management, since although there is a standard way to select more than one file to be sent through multipart-data forms, no browsers actually support it (or to be more correct, only latest versions of Firefox do that). After some more tests, we noticed that it wasn’t a Mozilla issue, since the problem happened on Safari too and the responsibility of the reported crash had to be assigned to the Flash Player plugin… but why that happens on Mac OS X only?

Taking a look on Google, we found out that Wordpress’ uploader suffers the same problem, since it uses a Flash component as multiple file selector too… So, we weren’t the only ones in trouble!

In these cases, GDB could give quite interesting information: running this debugger attached to a Firefox process, we found that:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0×15b0a000
0xffff08a0 in _memcpy () at /System/Library/Frameworks/System.framework/PrivateHeaders/i386/cpu_capabilities.h:246
246 /System/Library/Frameworks/System.framework/PrivateHeaders/i386/cpu_capabilities.h: No such file or directory.
in /System/Library/Frameworks/System.framework/PrivateHeaders/i386/cpu_capabilities.h
(gdb) bt
#0 0xffff08a0 in _memcpy () at /System/Library/Frameworks/System.framework/PrivateHeaders/i386/cpu_capabilities.h:246
#1 0×952966a3 in dataRead ()
#2 0×952e512d in CFReadStreamRead ()
#3 0×92269532 in HTTPNetConnection::transmitRequest ()
#4 0×92269860 in HTTPNetConnection::requestStreamCallback ()
#5 0×922673c1 in NetConnection::connectionRequest ()
#6 0×952e25a9 in _CFStreamSignalEventSynch ()
#7 0×952e4147 in CFWriteStreamSignalEvent ()
#8 0×9226fe91 in HTTPWriteFilter::streamFilterCallback ()
#9 0×92270503 in HTTPWriteFilter::_httpWrFilterStreamCallBack ()
#10 0×952e25a9 in _CFStreamSignalEventSynch ()
#11 0×952e4147 in CFWriteStreamSignalEvent ()
#12 0×92277bef in SocketStream::socketCallback ()
#13 0×92277cd1 in SocketStream::_SocketCallBack_stream ()
#14 0×952d97b1 in __CFSocketDoCallback ()
#15 0×952daf65 in __CFSocketPerformV0 ()
#16 0×952d063f in CFRunLoopRunSpecific ()
#17 0×952d0cd8 in CFRunLoopRunInMode ()
#18 0×946da2c0 in RunCurrentEventLoopInMode ()
#19 0×946da012 in ReceiveNextEventCommon ()
#20 0×946d9f4d in BlockUntilNextEventMatchingListInMode ()
#21 0×90af7d7d in _DPSNextEvent ()
#22 0×90af7630 in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] ()
#23 0×90af066b in -[NSApplication run] ()
#24 0×0141ff89 in JSD_GetValueForObject ()
#25 0×012e5b21 in XRE_GetFileFromPath ()
#26 0×00cafaed in XRE_main ()
#27 0×00001d25 in start ()
Current language: auto; currently asm

WOW! Something’s triggering a failure in a part of Mac OS X’s CoreFoundation on i386 systems! And this actually fired trying to close the page while the Flash component was still uploading a file…

How to manage and correct this? On our side, the best thing we can do is trying to force the closure of pending connections using SWFUpload’s Javascript exposed methods, which effectively saves the browser from an unrelenting crash if our user clicks on the “cancel” button, but still doesn’t save from the eventuality of a less polite closure of the page.

Anyway, this highlights two facts: last version 10 of Adobe’s Flash Player still causes some problems and Apple’s transition to x86 platform has still something to be fixed.

Tags: osx