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: 0x15b0a000
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.
#0 0xffff08a0 in _memcpy () at /System/Library/Frameworks/System.framework/PrivateHeaders/i386/cpu_capabilities.h:246
#1 0x952966a3 in dataRead ()
#2 0x952e512d in CFReadStreamRead ()
#3 0x92269532 in HTTPNetConnection::transmitRequest ()
#4 0x92269860 in HTTPNetConnection::requestStreamCallback ()
#5 0x922673c1 in NetConnection::connectionRequest ()
#6 0x952e25a9 in _CFStreamSignalEventSynch ()
#7 0x952e4147 in CFWriteStreamSignalEvent ()
#8 0x9226fe91 in HTTPWriteFilter::streamFilterCallback ()
#9 0x92270503 in HTTPWriteFilter::_httpWrFilterStreamCallBack ()
#10 0x952e25a9 in _CFStreamSignalEventSynch ()
#11 0x952e4147 in CFWriteStreamSignalEvent ()
#12 0x92277bef in SocketStream::socketCallback ()
#13 0x92277cd1 in SocketStream::_SocketCallBack_stream ()
#14 0x952d97b1 in __CFSocketDoCallback ()
#15 0x952daf65 in __CFSocketPerformV0 ()
#16 0x952d063f in CFRunLoopRunSpecific ()
#17 0x952d0cd8 in CFRunLoopRunInMode ()
#18 0x946da2c0 in RunCurrentEventLoopInMode ()
#19 0x946da012 in ReceiveNextEventCommon ()
#20 0x946d9f4d in BlockUntilNextEventMatchingListInMode ()
#21 0x90af7d7d in _DPSNextEvent ()
#22 0x90af7630 in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] ()
#23 0x90af066b in -[NSApplication run] ()
#24 0x0141ff89 in JSD_GetValueForObject ()
#25 0x012e5b21 in XRE_GetFileFromPath ()
#26 0x00cafaed in XRE_main ()
#27 0x00001d25 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…
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.