Access violation in BORLNDMM.DLL with no debug information

"Jeremy R. Wright" <> a crit dans le message news:

> I'm receiving an access violation, and because of the lack of debugging
> information, the error seems to be impossible to track down.

> In my application, I am creating and then destroying a particular form
> repeatedly. The access violation is thrown usually the second or third
> the form is created, somewhere in the code for TForm::TForm (TForm's
> constructor). However, once the exception is shown and I return back to
> de{*word*81}, the call stack only displays one entry, pointing to some address
> inside BORLNDMM.DLL. Unfortunately there is no debugging information
> the DLLs assembly, leaving me even more in the dark. If I try to continue
> running the program it just throws the same exception, looping infinitely.

> The form I am creating is derived from another form, which is derived from
> yet another form, which is then derived from TForm. In other words, my
> has several parent classes in between it and TForm. One of my form's
> (sister?) forms (i.e. shares the same parent) has none of the above
> problems. It would follow that I should try and compare the two forms and
> see what's different, but that's much harder than it seems, because I
> write the code for either one, and there would be LOTS of it to go

> Adding to the confusion, running alongside my app is another
> app which reads from the serial port and communicates back and forth with
> problematic form using WinAPI message calls. I'm wondering if this has
> something to do with why no debug info appears. Perhaps it's an error that
> comes up when the two apps are trying to share mem space or something, but
> neither one is really in context.

> Basically, I'm just wondering if someone out there has ever run across
> sort of error? Maybe someone can explain to me what the BORLNDMM.DLL
> is? I imagine the MM stands for memory manager, but there isn't much
> reference to it anywhere in the help.

It's exactly that : memory manager.
However, at 99.99 % chance the problem comes
from your app code.

So, you should post how you create this particular form
and how it is destroyed. Is it an MDI app or not ?
Do you explicitly set the Parent property ?
Auto destroyed ? Action = caFree in the Onclose event ?
Destroyed by code : delete MyForm; ?