Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 5 of 5 total
Thread Old versions of FastMM can cause crashes
Tue, Feb 12 2008 11:08 PMPermanent Link

Oliver Bock
After upgrading to DBISAM 4.26 I started having a crash when running in
client/server mode.  Over many hours I stripped bits off my application
to find out what the problem was.  It turned out that the version of
FastMM I was building into my server (4.58) was incompatible with DBISAM
(which now includes a later version of FastMM).  Everything is now fine:
 I have upgraded my FastMM to the latest version (v4.78).


  Oliver
Wed, Feb 13 2008 5:03 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Oliver,

<< After upgrading to DBISAM 4.26 I started having a crash when running in
client/server mode.  Over many hours I stripped bits off my application to
find out what the problem was.  It turned out that the version of FastMM I
was building into my server (4.58) was incompatible with DBISAM (which now
includes a later version of FastMM).  Everything is now fine:  I have
upgraded my FastMM to the latest version (v4.78). >>

We don't re-distribute FastMM, so I'm curious as to how there was an issue
with "compatibility".   Did you mean to say that there was simply an issue
with the older version of FastMM ?

--
Tim Young
Elevate Software
www.elevatesoft.com

Sun, Feb 17 2008 6:46 PMPermanent Link

Oliver Bock
Tim Young [Elevate Software] wrote:
> We don't re-distribute FastMM, so I'm curious as to how there was an issue
> with "compatibility".   Did you mean to say that there was simply an issue
> with the older version of FastMM ?

I removed FastMM 4.58 from my DBISAM server project and the crash
disappeared.  When I re-added the latest FastMM the problem stayed gone,
so I concluded that somehow the two memory managers are interacting, and
were incompatible.  At this point I posted my first message.

The crash has recently reappeared and I have since determined that this
was because I had re-enabled FastMM's FullDebugMode and friends.
Probably this was the problem all along, rather than having to do with
the specific version of FastMM.

Does this make sense?  I read your release notes to indicate that your
code is built with FastMM, but I have no idea how the memory manager
used by the code in your DLL interacts with the code in my EXE.

The other possibility is that something is reusing freed objects or
otherwise misusing memory.  According to this theory FastMM4's
FullDebugMode's practice of clearing the contents of destroyed objects
is revealing the bug.

My sample project works as follows:

Server project: starts a server and makes a server procedure available.
 When called, the server procedure opens a TDBISAMTable connected to a
memory table and then destroys it.

Client project: connects to the server, creates a memory table, calls
the server procedure, and drops the memory table.  When I close the
client application (and thus disconnect from the server) I get a crash
on the server.

I have e-mailed the project to you in case you want to take a look.
Hopefully I am doing something stupid.


  Oliver
Mon, Feb 18 2008 5:10 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Oliver,

<< I have e-mailed the project to you in case you want to take a look.
Hopefully I am doing something stupid. >>

I've fixed it now, and a fix will be in the next 4.26 build.

--
Tim Young
Elevate Software
www.elevatesoft.com

Mon, Feb 18 2008 5:49 PMPermanent Link

Oliver Bock
Brilliant!  Thanks for the quick response.


Tim Young [Elevate Software] wrote:
> Oliver,
>
> << I have e-mailed the project to you in case you want to take a look.
> Hopefully I am doing something stupid. >>
>
> I've fixed it now, and a fix will be in the next 4.26 build.
>
Image