"Brent W. Baccala" <cos...@freesoft.org> writes: > My new and improved rpctrace is generating kernel panics when run on > ext2fs. This happens when rpctrace calls gsync_wait, with ext2fs as the > 'task' argument.
Could gsync_wait be removed from gnumach.defs and replaced with only a trap that does not take a task_t parameter and cannot be intercepted by rpctrace? (If the gsync code is not deleted altogether because of the license conflict.) > Even if I'm right about the nature of this bug, I don't understand gnumach > well enough to know how a task should access another task's memory. vm_copy apparently supports such access; code from there could be reused. But if rpctrace uses gsync_wait on the address space of another task and the page has been paged out, then the call could end up blocking for the pager, and I don't think you want that.
