Thanks Bart. There's certainly no rush - I think I can survive a few more
weeks of leaking hlists!
> so the net effect is that we have one hlist leaking -- and after 256
> times doing this, the hlist stack is full.
Yeah I see that in the debug log:
MFS: hlist_push: 256 hlist=0x8371ae8 PSP=40251
MFS: hlist_push: past maximum stackMFS: find_again entered with . .
MFS: Directory ---> YES 0x41ed
MFS: '. '.' ' hlist=-1
MFS: Finished dos_fs_redirect
MFS: Entering dos_fs_redirect, FN=1C
MFS: selecting drive fn=1c sda_cds=0x7720
MFS: selected drive 2: /var/lib/dosemu/dos7boot/
MFS: Find next ????????.???, pointer->hlist=0
MFS: find_again entered with (null).^V
MFS: No more matches
MFS: hlist_pop: 256 popping=65535 PSP=40251
I would think a circular list would solve the problem, especially if the
list size is big enough. Is a circular list with 256 entries large
enough? (From looking at mfs.c it looks like hlist_stack_size was once
set to 32.) Is there a risk in increasing the hlist stack size beyond
256?
Regardless of list size, would a change to mfs.c like this work:
static __inline__ int
hlist_push(struct dir_ent *hlist, unsigned psp)
{
Debug0((dbg_fd, "hlist_push: %d hlist=%p PSP=%d\n", hlist_stack_indx,
hlist, psp));
if (hlist_stack_indx >= HLIST_STACK_SIZE) {
Debug0((dbg_fd, "hlist_push: past maximum stack"));
- return -1;
+ hlist_stack_indx = 0;
+ hlist_stack[hlist_stack_indx] = hlist;
+ hlist_psp_stack[hlist_stack_indx] = psp;
+ return hlist_stack_indx++;
}
else {
hlist_stack[hlist_stack_indx] = hlist;
hlist_psp_stack[hlist_stack_indx] = psp;
return hlist_stack_indx++;
}
}
Have a good vacation!
Dan
-
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
