mORMot Open Source

ssoftpro

Member

Registered: 2017-11-14

Posts: 7

Use of FastMM4 causes a bug in SetLength

While compiling mORMot with the latest master version of FastMM4 on Linux 64 bit using either FPC 3.0.4 or 3.3.1 I'd encountered a strange error: when writing large (~50K) buffers into TRawByteStringStream, the content of the internal string became corrupt after on 6-7th write. This depends on the size of the buffer written and reproducible for buffers 45, 50, 55Kb in length. In addition, I've discovered that it is enough to temporarily save a pointer to the internal string in TRawByteStringStream.Write to eliminate this error. I assume this is because FastMM releases memory too early when a string is enlarged. In order to prevent any influence I've created a synthetic test and got the same error.

ab

Administrator

From: France

Registered: 2010-06-21

Posts: 14,661

Website

Re: Use of FastMM4 causes a bug in SetLength

Weird.
Does it mean that SetLength() isn't making the string unique?

Do you think it is a TRawBytestringStream bug?
TRawByteStringStream.Write is used on production since year, with no problem, but either with Delphi, or with FPC but with its original MM (not FastMM4).

mpv

Member

From: Ukraine

Registered: 2012-03-24

Posts: 1,571

Website

Re: Use of FastMM4 causes a bug in SetLength

No - this is definitely not a bug of TRawBytestringStream (streams without FastMM work well under linux/ftpc), but a bug (particularity?) in FastMM for FPC->Linux64