Hello,

I got an AV in the CMem unit. To reproduce the problem just compile and run this code below:

=== code ===

program project1;
{$mode delphi}
uses
  Classes, SysUtils, cmem;
var
  VBuffer: TBytes;
  VStream: TStream;
begin
  VStream := TBytesStream.Create;
  try
    VBuffer := TEncoding.UTF8.GetBytes('abc');
    VStream.WriteBuffer(VBuffer[0], Length(VBuffer));
  finally
    VStream.Free;
  end;
end.

=== /code ===

=== error ===

C:\Users\silvioprog\Desktop\av>project1.exe
An unhandled exception occurred at $00410479:
EAccessViolation: Access violation
$00410479
$00410542

Heap dump by heaptrc unit
70 memory blocks allocated : 1972/2104
67 memory blocks freed : 1792/1920
3 unfreed memory blocks : 180
True heap size : 262144 (96 used in System startup) True free heap : 261632
Should be : 261672
Call trace for block $015C8480 size 64
$00409B9C
$004169A7
$0040AACE
$00410542
Call trace for block $015C0478 size 24
$00409B9C
$004169A7
$0040AACE
$00410542
Call trace for block $015B8470 size 92
$0041687F
$0040AACE
$00410542
$0077006F
$005C0073
$00790073
$00740073
$006D0065

=== /error ===

The project was compiled with -gh option. If you comment the "cmem" declaration, the problem is over.

To fix my problem I declared the functions Malloc() and Free() directly in my project, but even so I thought it was interesting to report this error.

1. Shouldn't Cmem be the first unit in your program's uses clause?
2. Maybe http://bugs.freepascal.org/view.php?id=29759

Bart

"silvioprog" wrote

Hello, I got an AV in the CMem unit. To reproduce the problem just compile and

run this code below:

[Snip]

=== /code ===

*Always* put an alternate memory manager as the first unit. I think that requirement is even documented somewhere...
Also don't use -gh with alternate memory managers. They are *both* memory managers and thus will lead to conflicting situations.

Regards,
Sven

First paragraph.

http://freepascal.org/docs-html/current/rtl/cmem/index.html

Michael.

Now I declared it as first unit in my program, and the problem was:

=== error ===

C:\Users\silvioprog\Desktop\av>project1.exe
An unhandled exception occurred at $0040B8E2:
EAccessViolation: Access violation
$0040B8E2

=== /error ===

On Tue, Mar 8, 2016 at 4:02 AM, Sven Barth
wrote:
[...]

*Always* put an alternate memory manager as the first unit. I think that requirement is even documented somewhere...

Thanks for share this information.

Also don't use -gh with alternate memory managers. They are *both* memory managers and thus will lead to conflicting situations.

Hmmmm... I didn't know about this conflicting, thanks again! :-)

Is there some way to report possible memory leaks when my memory manager is the cmem?

Now I omitted the -gh and declared the units as:

=== code ===

uses
  cmem, Classes, SysUtils;

=== /code ===

And the problem was:

=== error ===

C:\Users\silvioprog\Desktop\av>project1.exe
An unhandled exception occurred at $0040B8E2:
EAccessViolation: Access violation
$0040B8E2

=== /error ===

On Tue, Mar 8, 2016 at 5:54 AM, Michael Van Canneyt wrote:
[...]

First paragraph. http://freepascal.org/docs-html/current/rtl/cmem/index.html

This Sven explanation below should be added there too:

'Also don't use -gh with alternate memory managers. They are *both* memory managers and thus will lead to conflicting situations.'

I tried that and the code runs fine on my system.

Michael.

On Tue, Mar 8, 2016 at 8:42 AM, Michael Van Canneyt wrote:
[...]

I tried that and the code runs fine on my system.

Linux?

(my environment: Lazarus 1.7 rUnknown FPC 3.1.1 i386-win32-win32/win64)

silvioprog wrote

(my environment: Lazarus 1.7 rUnknown FPC 3.1.1 i386-win32-win32/win64)

I can run simple Lazarus GUI program that uses CMem. Lazarus 1.7 r51837 FPC 3.0.0 i386-win32-win32/win64. (32-bit)

Bart

Linux, 64 bit.

Michael.

Can you test this attached program?

On Tue, Mar 8, 2016 at 9:48 AM, Michael Van Canneyt wrote:
[...]

Linux, 64 bit.

I'll check it on my Xubuntu ...

Runs fine on Linux, 64 bit, built both with lazbuild, and with fpc on command-line.

Michael.

silvioprog wrote

Can you test this attached program?

Builds and runs fine, both 64 and 32 bit, inside and outside the debugger. Tested on Win7-64.

Bart

I use CodeTyphon for programming. New version have similar error. CodeTyphon-570 use FreePascal 3.1.1 Source 02-03-2016 SVN Rev 33143 with some modification by CT people.
For CT-570 I use solution like this.
Basically remove cmem when in debug mode. For production (without debug) use cmem.

program TestSerial;
{$mode objfpc}{$H+}
uses
{$IFOPT D-}
cmem, // CT570 does not like debug mode with cmem
{$ENDIF}
{$IFDEF UNIX}{$IFDEF UseCThreads}
cthreads,
{$ENDIF}{$ENDIF}
Interfaces, // this includes the LCL widgetset
Forms, FrmMainTestSerial
{ you can add units after this };
{$R *.res}
begin
RequireDerivedFormResource := True;
Application.Initialize;
Application.CreateForm(TfMainTestSerial, fMainTestSerial);
Application.Run;
end.

Strange. I got it on my Windows:

http://ctrlv.in/725499

http://ctrlv.in/725501

I use this batch to build my FPC from trunk on Windows:

http://pastebin.com/V1mZdPvK

On Tue, Mar 8, 2016 at 12:10 PM, Michael Van Canneyt <

Strange, I got same error on my Xubuntu 64 bits:

http://ctrlv.in/725502 (SIGSEGV)

http://ctrlv.in/725503 (Assembler)

FPC 3.1.1 from trunk compiled tonight.

program project1;
{$mode delphi}
uses
  cmem,
  Classes, SysUtils;
var
  VBuffer: TBytes;
  VStream: TStream;
begin
  VStream := TBytesStream.Create;
  try
    VBuffer := TEncoding.UTF8.GetBytes('abc');
    VStream.WriteBuffer(VBuffer[0], Length(VBuffer));
  finally
    VStream.Free;
  end;
  writeln('Press any key to finish...');
  readln;
end.

I tried this with CT540 - it is OK
CT570 with newer compiler gets access violation when in debug. If you try application from command prompt then it is OK.

Picture attached
<http://free-pascal-general.1045716.n5.nabble.com/file/n5724518/AccessViolationCmem.png>

This points to an error in CodeTyphon, not Free Pascal. What are the options used to compile the program ? Does it include -gh ? If so, then that is almost certainly the problem.

Michael.

Opitions are like that (defaults) - does not include -gh (no heap trace)

-MObjFPC -Scghi -O1 -g -gl -l -vewnhibq
-FiC:\codetyphon\typhonTemp\lib\i386-win32
-FUC:\codetyphon\typhonTemp\lib\i386-win32\ -FEC:\codetyphon\typhonTemp\

Note - this is first time that Typhon behave this was. Even, beta version of CT570 was OK considering this error, so I assume something does not behave as it was before. They suggest (CT people) on its forum that we should not use cmem in debug mode because they have to fix it deeply (or something like that. If I understood correctly) ?!?!?

Regards, Dinko