Problem 1:
authorjaw <jaw>
Tue, 14 Feb 2006 23:50:15 +0000 (23:50 +0000)
committerjaw <jaw>
Tue, 14 Feb 2006 23:50:15 +0000 (23:50 +0000)
commitbe4e94a2fdde1f5ff2671c80f737af012be7179c
tree94437976363febfd9cdd87000a682d1612e680d4
parent058fc1d8d19f93acc67a2a782d6609408b7316c0
Problem 1:

Historically Dyninst does a sleep(1) after receiving notification of a
fork() exit to allow the OS time to fully create the process.  Somehow
this went missing in the recent re-org of the fork handling code and all
hell broke loose.

Its not the best solution, but I just put it back.

Problem 2:

The mailbox system is quite flexible, what with being able to handle
recursive chains of callbacks, but the downside of this flexibility is
that it requires outside hints as to when it is ok to delete a callback
that has already been executed.

It is bad, for example, to delete a callback that is waiting for the
completion of another callback, or, more likely, to delete a callback when
we are later going to need to query it for its return value.

The memory clobber that we were seeing was actually correct behavior --
from the perspective of the mailbox.  Certain callbacks were being
deleted after being executed.  The error was that these callbacks
should've known better and indicated that it was not safe to delete them
until the desired event had been received.
16 files changed:
dyninstAPI/h/BPatch_eventLock.h
dyninstAPI/src/BPatch.C
dyninstAPI/src/BPatch_eventLock.C
dyninstAPI/src/BPatch_process.C
dyninstAPI/src/EventHandler.C
dyninstAPI/src/callbacks.C
dyninstAPI/src/callbacks.h
dyninstAPI/src/linux.C
dyninstAPI/src/mailbox.C
dyninstAPI/src/process.C
dyninstAPI/src/signalhandler.C
dyninstAPI/src/sol_proc.C
dyninstAPI/src/unix.C
dyninstAPI/src/util.C
dyninstAPI/src/util.h
dyninstAPI/tests/src/test4a.mutatee.c