: end =3D vm->vm_daddr + ctob(vm->vm_dsize);
: obreak(vm, end + size);
: vm_map_protect(&vm->vm_map, end, end + size, VM_PROT_READ);
:
:And vm_map_protect() will create new map entry (it should, right?)
:with entry->start =3D end and entry->end =3D end + size.
:
:But what happend with those entries when execve() is called?
:Because process' map catched before execve() doesn't exists after
:execve() is called. So maybe those entries (with VM_PROT_READ) are
:reused somehow?
:
:THANKS!
:
:--=20
:Pawel Jakub Dawidek [EMAIL PROTECTED]
Hmm. Well, when a process forks the vm_map_entry's fork along with
it. The underlying VM objects remain shared but become copy-on-write.
It sounds like whatever you are doing is messing up the user stack, and
the program is bus-faulting when it can't write to the user stack.
All sorts of things have to write to the user stack, including the
signal trampoline code and even execve().
The fault address you reported earlier, 0xbfbffc20, is on the user stack.
-Matt
_______________________________________________
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
