osx
Flash and Mac OS X bug while interrupting connections
Sunday, March 1st, 2009 | Web | Comments
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.
Remember to sync (or what the heck is that RAW C: partition on my Windows on mac?)
Friday, August 15th, 2008 | Computer Science | Comments
Our current computers use MBR to store the table of primary partitions. MBR for convention allows only 4 primary partitions and then uses Logical Partitions inside Extended Boot Records for the successive. Instead Apple computers use the new Extensible Firmware Interface with the GUID Partition Table to describe disk partitions permitting any number of primary partitions to be allocated.
MacOSX uses the GPT partition table while Windows expects to find the MBR one (Actually Windows for Itanium can boot from GPT, but that is not what you are usually installing on your desktop). Fortunately the EFI keeps a “fake” MBR table for backward compatibility and that is why we can install Windows on our MacIntel. But what happens when we change our GPT partitions from OSX/Linux which supports GPT? It happens that our MBR becames out of sync with the GPT.
Recently I had to install a triple boot with OSX+Win+Linux on my MacBookPro. This required 5 partitions (1 for EFI, 1 for OSX, 1 for Linux, 1 for Windows, 1 Linux Swap). After creating them from OSX I synchronized the MBR to GPT with refit tools to have the first four partition available also on MBR (this way I lost only the SWAP partition) then I installed Windows XP. Everything went well but after booting, Windows ended up installing on D: and there was a C: partition resulting of RAW type. I just thought that obviously this was because there was the un-formatted Linux partition before the Windows one and restarted to install Linux.
Then I formatted my linux partition as EXT3 and installed Gentoo over it. Everything was fine until I had to restart windows to install the Service Pack 3 for XP. My wonderful RAW C: partition was still there… and I wasn’t able to install the service pack because SP3 installer wasn’t able to install on anything else then C: even if my Windows installation resulted on D: and C: didn’t result as a valid partition (off course… It’s my Linux partition!)
Windows should have known that it isn’t a valid partition for him and should hide it, that didn’t happen… Why? After thinking a bit I remembered that the Partition Type is also a field inside the MBR. When we format a partition the system specifies also the partition type inside the MBR to tell everyone that partition has been reserved by some OS. Having initialized my EXT3 partition from Linux had as a result that only the GPT was updated and the MBR still thought that my third partition was un-formatted.
After losing about an hour fighting with the Service Pack installer I just realized that I had to resynchronize the two tables… After doing that the RAW C: partition disappeared from Windows and my service pack installed correctly.
New Lesson: Ok, Microsoft could make a better installer and stop preventing their OS to install from something different from what they call “C:” but sometimes you have to think more before enraging with your OS 