[1194] in Coldmud discussion meeting
[COLD] Patch
daemon@ATHENA.MIT.EDU (Wed Dec 25 00:44:39 1996
)
Date: Wed, 25 Dec 1996 06:30:18 +0100 (MET)
From: Miroslav Silovic <Miroslav.Silovic@public.srce.hr>
To: coldstuff@cold.org
No, I haven't found the db corruption. I suspected we might have a problem
with fork_method, but I could not substantiate this suspicion any further
(I'd say it's 50-50, but bear in mind that current ColdCore calls it more
than any other core). The bug might even vanish with the fix to cancel() -
is it called often? If it's not, my first bet is still the hardware, till I
see better candidate, or till someone else's db starts to decay. :)
This fix removes the memory leak associated with task_info. It also
fixes the bug with cancel() /someone please take a look at this. I *think*
this is okay, but should there be something else in place of the
commented code? - it stored the task that called cancel() into the list
of free tasks, and bombed the driver that way. Enjoy the patches:
*** /tmp/x/Genesis-1.0p21/src/execute.c Sat Dec 21 08:22:52 1996
--- execute.c Wed Dec 25 05:53:59 1996
***************
*** 264,273 ****
--- 264,274 ----
dl[6].type = INTEGER;
dl[6].u.val = vm->limit_calldepth;
/* frames */
list = list_add(list, &d);
+ data_discard(&d);
d.type = LIST;
frame = vm->cur_frame;
while (frame) {
d.u.list = frame_info(frame);
list = list_add(list, &d);
***************
*** 393,403 ****
else
REMOVE_TASK(suspended, vm)
store_stack();
ADD_TASK(vmstore, vm);
restore_vm(old_vm);
! ADD_TASK(vmstore, old_vm);
}
/*
// ---------------------------------------------------------------
*/
--- 394,404 ----
else
REMOVE_TASK(suspended, vm)
store_stack();
ADD_TASK(vmstore, vm);
restore_vm(old_vm);
! /* ADD_TASK(vmstore, old_vm); */
}
/*
// ---------------------------------------------------------------
*/