#1 2018-01-07 15:43:07

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.


#2 2018-01-07 20:29:49

From: France
Registered: 2010-06-21
Posts: 14,310

Re: Use of FastMM4 causes a bug in SetLength

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).


#3 2018-01-09 08:00:20

From: Ukraine
Registered: 2012-03-24
Posts: 1,561

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


Board footer

Powered by FluxBB