Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / lazarus / 2011-02

Memory corruption when allocating and freeing 1 byte memory

5 messages · 2 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Juha Manninen

Hi

I fixed a nasty memory corruption issue in r29667. It happens when TRegExpr is passed an empty source file. SearchFrm.pas has:

     RE.InputString:=Src;

Then GetMem reserves only 1 byte of memory.
Then FreeMem causes a crash and Lazarus dies (in my machine, in certain conditions):

Marked memory at $00007F806D2E3D00 invalid
Wrong signature $1BD5F2DE instead of 4125C513
$00000000005D12E2 line 678 of ../inc/heaptrc.pp
$00000000005D1401 line 718 of ../inc/heaptrc.pp
$00000000005C4586 line 291 of ../inc/heap.inc
$0000000000F90D8A line 1187 of synregexpr.pas
$00000000005BDD8F line 278 of ../inc/objpas.inc
$00000000005F0C23 line 132 of ../objpas/sysutils/sysutils.inc $0000000001155D54 line 603 of searchfrm.pas
$0000000001158607 line 873 of searchfrm.pas
$0000000001157C34 line 780 of searchfrm.pas

No useful backtrace was available from gdb and I was looking for the reason for some time.
This may be a bug in FPC heap manager (?) maybe related to 64-bits. My system is AMD 64-bit Fedora Linux.

The strange thing is that I experienced the crash only with QT bindings although the problem has nothing to do with widget bindings. Strange...
I bet most developers can't reproduce my findings (again).

Juha

Reply by email

Juha Manninen
to Juha Manninen
Show quoted text 6 lines
The strange thing is that I experienced the crash only with QT bindings although the problem has nothing to do with widget bindings. Strange... I bet most developers can't reproduce my findings (again).

I could not reproduce it myself on a mini-laptop. It may be a 64-bit issue.

Juha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110225/94a172c6/attachment.html>

Reply by email

Vincent Snijders
to Juha Manninen: Hi I fixed a nasty memory corruption issue in r29667. It happens when TRegExpr is passed…

2011/2/25 Juha Manninen :

Show quoted text 33 lines
Hi I fixed a nasty memory corruption issue in r29667. It happens when TRegExpr is passed an empty source file. SearchFrm.pas has: ? ? RE.InputString:=Src; Then GetMem reserves only 1 byte of memory. Then FreeMem causes a crash and Lazarus dies (in my machine, in certain conditions): Marked memory at $00007F806D2E3D00 invalid Wrong signature $1BD5F2DE instead of 4125C513 ?$00000000005D12E2 line 678 of ../inc/heaptrc.pp ?$00000000005D1401 line 718 of ../inc/heaptrc.pp ?$00000000005C4586 line 291 of ../inc/heap.inc ?$0000000000F90D8A line 1187 of synregexpr.pas ?$00000000005BDD8F line 278 of ../inc/objpas.inc ?$00000000005F0C23 line 132 of ../objpas/sysutils/sysutils.inc ?$0000000001155D54 line 603 of searchfrm.pas ?$0000000001158607 line 873 of searchfrm.pas ?$0000000001157C34 line 780 of searchfrm.pas No useful backtrace was available from gdb and I was looking for the reason for some time. This may be a bug in FPC heap manager (?) maybe related to 64-bits. My system is AMD 64-bit Fedora Linux. The strange thing is that I experienced the crash only with QT bindings although the problem has nothing to do with widget bindings. Strange... I bet most developers can't reproduce my findings (again).

It probably is some buffer overrun, at least that is more likely than a bug in the heap manager.

WIthout sample source that can be compiled and run it is hard to draw any conclusion form the heaptrc and I doubt that anybody can reproduce your findings.

Vincent

Reply by email

Juha Manninen
to Vincent Snijders

Vincent Snijders kirjoitti lauantai 26 helmikuu 2011 10:27:19:

Show quoted text 6 lines
It probably is some buffer overrun, at least that is more likely than a bug in the heap manager. WIthout sample source that can be compiled and run it is hard to draw any conclusion form the heaptrc and I doubt that anybody can reproduce your findings.

True. The actual bug is still hiding somewhere.
It is annoying that there is no systematic way to trap bugs, although we have compiler features like range checks and heap tracer. Sometimes a completely unrelated change in code triggers a bug to show up. My 3-CPU-core computer seems to be good at revealing some bugs that nobody else can reproduce.

If someone wants to try to reproduce it, this is what I did:
- Latest Lazarus trunk and FPC trunk versions.
- 64-bit AMD CPU, Linux.
- Lazarus built with QT bindings (GTK2 bindings did not show the bug)
- Find in File (Shift-Ctrl-F),

  Text to find: "Color ?:="
  Options: Regular expressions
  Where: Search in directories
  Directory: Lazarus source directory + Include sub directories

The search first finds 902 matches, then file
components/codetools/examples/scanexamples/empty.inc causes the crash.
In total there are around 2000 matches.

The buffer overrun is most likely in the TRegExpr component. It uses PChar and GetMem while it could just use strings which are more resistant against memory corruption issues.

Juha

Reply by email

Juha Manninen
to Vincent Snijders: 2011/2/25 Juha Manninen : It probably is some buffer overrun, at least that is more…

Vincent Snijders kirjoitti lauantai 26 helmikuu 2011 10:27:19:

It probably is some buffer overrun, at least that is more likely than a bug in the heap manager.
Replacing:
  GetMem (fInputString, (Len + 1) * SizeOf (REChar));
with:
  GetMem (fInputString, (Len + 2) * SizeOf (REChar));

in TRegExpr code also cures the problem,
although it may again hide the actual problem.

Juha

Reply by email