Folks, I'm running into a problem with I/O which has me puzzled - when I copy a file from a disk mounted by my filesystem, to the boot drive (HFS extended), it works fine, and the resulting file can be opened and read properly. However, when I try to open the same file directly with an application such as Preview, the Preview application crashes as follows: ********** Date/Time: 2003-07-16 16:35:40 -0700 OS Version: 10.2.6 (Build 6L60) Host: schizm.local. Command: Preview PID: 521 Exception: EXC_BAD_ACCESS (0x0001) Code[0]: 0x0000000aCode[1]: 0x01cef000 Thread 0 Crashed: #0 0x9323fc3c in -[NSBMPImageReader getByte] #1 0x9323fdd0 in -[NSBMPImageReader loadBitmapFileHeader] #2 0x932406ec in -[NSBMPImageReader loadImageHeader] #3 0x930ef4a4 in -[NSBitmapImageRep _initWithImageReader:] #4 0x930bd388 in +[NSBitmapImageRep _imagesWithData:hfsFileType:extension:zone:] #5 0x9310e4b8 in +[NSBitmapImageRep _imageRepsWithData:hfsFileType:extension:] #6 0x930e02a4 in +[NSImageRep imageRepsWithContentsOfFile:] #7 0x9312e68c in -[NSImage initWithContentsOfFile:] #8 0x0000c9b4 in 0xc9b4 #9 0x00009c20 in 0x9c20 #10 0x00004e98 in 0x4e98 #11 0x00004ab0 in 0x4ab0 #12 0x931c4a9c in -[NSDocumentController _openDocumentFileAt:display:] #13 0x000112a4 in 0x112a4 #14 0x930f9cac in -[NSApplication sendAction:to:from:] #15 0x9316ec5c in -[NSMenu performActionForItemAtIndex:] #16 0x931af2fc in -[NSCarbonMenuImpl performActionWithHighlightingForItemAtIndex:] #17 0x930ec730 in _NSHandleCarbonMenuEvent #18 0x9308e22c in _DPSNextEvent #19 0x930a0158 in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] #20 0x930b1d88 in -[NSApplication run] #21 0x9315fc58 in NSApplicationMain #22 0x000046e0 in 0x46e0 #23 0x00004560 in 0x4560 Thread 1: #0 0x90014d28 in syscall_thread_switch #1 0x97e03ef4 in +[NSThread sleepUntilDate:] #2 0x93081cac in -[NSUIHeartBeat _heartBeatThread:] #3 0x97e2cc50 in forkThreadForFunction #4 0x90020d48 in _pthread_body PPC Thread State: srr0: 0x9323fc3c srr1: 0x0200f030 vrsave: 0x00000000 xer: 0x00000000 lr: 0x9323fdd0 ctr: 0x9323fc0c mq: 0x00000000 r0: 0x00000000 r1: 0xbfffe460 r2: 0x00000000 r3: 0x01c4a250 r4: 0x906b679c r5: 0x01c4a250 r6: 0x00000010 r7: 0x00000010 r8: 0x000a1010 r9: 0x00000000 r10: 0x906852a8 r11: 0x01cef000 r12: 0x9323fc0c r13: 0x00000000 r14: 0x00000000 r15: 0x00000000 r16: 0x00000000 r17: 0xbffff770 r18: 0x00000000 r19: 0xffffffff r20: 0x00000000 r21: 0x01c4a250 r22: 0xa30a0060 r23: 0x00000000 r24: 0x001ef1a0 r25: 0x01c4afd0 r26: 0x01cef000 r27: 0x01c4afd0 r28: 0x00028c38 r29: 0x01c4a250 r30: 0x01c4a250 r31: 0x9323fd9c The exception (EXC_BAD_ACCESS) would indicate to me that Preview attempted to read a buffer which had been freed, but I'm not sure how this could have occurred. I should note here that my FS has a somewhat different I/O model from most BSD filesystems - because the FS core was written to be operating system independent, all of the buffer pointers passed through the FS core have to be located in kernel memory. As a result, my vnode_read routine works something like this: 1) MALLOC a buffer in kernel space the size of the read (uio_resid). 2) Call the FS core to read the data into the kernel buffer. 3) Call uiomove to copy the data to user memory. 4) FREE the kernel buffer. I assumed when I wrote that code, that it was going to be pretty inefficient, but according to "Kernel Programming: Boundary Crossings: Memory Mapping and Block Copying", its the best way to handle the problem:

In the Mac OS X kernel, data is most easily copied into kernel space

with the BSD copyin function, and back out to user space with the

copyout function. For large blocks of data, entire pages will be

memory mapped using copy-on-write. For this reason, it is generally

not useful to do memory mapping by hand.

Apparently, when I call uiomove, the kernel buffer is co-mapped into both kernel and user space, and then when I FREE the kernel buffer, it is un-mapped from kernel space, while the user space mapping remains. At least that's the theory. The code is so simple, that I wouldn't expect it be able to break, and if it did, I would expect a kernel panic. I certainly wouldn't expect it to work for Finder, and not for other applications. Any ideas? Thanks, Ron Aldrich Software Architects, Inc. _______________________________________________ darwin-kernel mailing list | darwin-kernel@lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.