I/O in my Filesystem causing application crashes.
I/O in my Filesystem causing application crashes.
- Subject: I/O in my Filesystem causing application crashes.
- From: email@hidden
- Date: Wed, 16 Jul 2003 17:35:50 -0700
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
_imagesWith
Data:hfsFileType:extension:zone:]
#5 0x9310e4b8 in +[NSBitmapImageRep
_imageRepsWith
Data: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 | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/darwin-kernel
Do not post admin requests to the list. They will be ignored.