Trap in Filter on shutdown while containers were still loading (at least I think they were still loading)

[Gregg Young]

I had FM2 open from my test directory and I opened my installed version (different directory) by dropping an object on it (testing to describe what %* does in the program objects). I closed it immediately following the initial drive scan (the directory container might have still been populating)and it trapped in Filter at the following line:

if (*mask->pszMasks[x]) Filter.c ~130

I can't reproduce the trap.

[Gregg Young]

x is 0. So the expection on the first pass through the while loop. mask->pszMasks[0] contained 00000788. EDI points to mask, but the .trp file is not sufficiently version to show the current content of EDI+208.

You might look at how mask was initialized. If the code does not memset the pszMasks array before some code tries to use it, this would explain the exception.

Take a look at

VOID SetMask?(PSZ maskstr, MASK *mask) Select.c ~532

After hitting send last night, I took a look at the initialization and mask is memset to zero at the same time as dcd is allocated and zeroed. This means the problem is unlikely to be an initialization problem.

Looking at the MASK structure, we have

typedef struct {

CHAR szMask[CCHMAXPATH]; CHAR szMaskCopy[CCHMAXPATH]; CHAR *pszMasks[26]; ...

} MASK;

I notice that there might be possibility that we can overflow szMask or szMaskCopy? If nothing else, we should add an overflow check at select.c:539 to ensure this can never occur. We should also complain if the user attempts to define more than 25 masks since the code depends on it. We know that the mask input routines limit the length of the string, but I prefer not to depend on this.

Looking at the MASK pointed to by EDI once again, I have to suspect that the exception occurred because the original dcd has already been freed and the memory reused. The data pointed to by EDI does not look like a MASK structure. This seems to be a likely possibility since you closed the the window before it filled. This kind of timing issue makes sense since it takes some time for the object window to notice that the GUI window is gone. We know that fm/2 contains code intended to handle this, but it may not be sufficiently robust for SMP systems.

[Gregg Young]

I have 6 trap dumps associated with this trap pdump.293-298

[Gregg Young]

CS [1786]