Sign in Join

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

Mailing lists / fpc-pascal / 2011-04

Problems with GetMem

5 messages · 3 people · –

Reply by email Subscribe to this list Your subscription

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

Unknown author

ZeelandNet Webmail

I get strange errors when using GetMem. In my
app I keep on allocating and freeing memory in a variable. At a certain moment I do keep getting a SIGSEGV on the GetMem call when trying to allocate exactly 128bytes. However allocating other sizes seems to work just fine. Is there some logical explanation what could be going on here? Is there a way for me to test the cause? I have tried to create a simple example that reproduces the error but without success, if needed I will post the entire library source, just wanted to ask first if I miss something obvious.

Regards, Darius

Reply by email

Jonas Maebe
to Unknown author
Show quoted text 6 lines
I get strange errors when using GetMem. In my app I keep on allocating and freeing memory in a variable. At a certain moment I do keep getting a SIGSEGV on the GetMem call when trying to allocate exactly 128bytes. However allocating other sizes seems to work just fine. Is there some logical explanation what could be going on here?

Most likely it's memory corruption: writing into a freed memory block, writing outside the bounds of an allocated memory block, ... Compiling with -gh may help pinpoint it, and if not and you're on a Unix-based platform, you can try Valgrind.

Jonas

Reply by email

Darius Blaszyk
to Jonas Maebe
Jonas Maebe wrote 11 lines
On 10 Apr 2011, at 00:20, wrote: > I get strange errors when using GetMem. In my > app I keep on allocating and freeing memory in a variable. At a certain > moment I do keep getting a SIGSEGV on the GetMem call when trying to > allocate exactly 128bytes. However allocating other sizes seems to work > just fine. Is there some logical explanation what could be going on > here? Most likely it's memory corruption: writing into a freed memory block, writing outside the bounds of an allocated memory block, ... Compiling with -gh may help pinpoint it, and if not and you're on a Unix-based platform, you can try Valgrind.

You're right that there seems to be a memleak somewhere, but it's something strange, heaptrc reports 1 unfreed block and 0bytes unfreed. Never seen this before. I will test with valgrind this afternoon to see if I can get some wiser from it. BTW, for those interested, I ported some code that allows bitmapped freetype fonts be used in OpenGL this works a lot simpler than using the freetype support from fcl-image. If you wish you can find the code here: http://scandraid.svn.sourceforge.net/viewvc/scandraid/src/branches/font/

Darius

bitmappedglfont

Marked memory at $0A5AF068 invalid
Wrong signature $9BC362D6 instead of D1853A22
$0040CFBB
$00407D08
$00401948 KEYPRESSED, line 80 of BitmappedGLFont.pas $0984E054
$0984D5DE
$7E418734
$7E418816
$7E42A013
$7E42A039
Heap dump by heaptrc unit
11894 memory blocks allocated : 8658563/8704536
11893 memory blocks freed : 8658563/8704536
1 unfreed memory blocks : 0
True heap size : 1146880 (160 used in System startup) True free heap : 1146384
Should be : 1146656
Marked memory at $0A5AF068 invalid
Wrong signature $9BC362D6 instead of D1853A22
$0040DE47
$0040CFBB
$00407D08
$00401948
$0984E054
$0984D5DE
$7E418734
$7E418816
$7E42A013

Reply by email

Jonas Maebe
to Darius Blaszyk
Darius Blaszyk wrote
You're right that there seems to be a memleak somewhere, but it's something strange, heaptrc reports 1 unfreed block and 0bytes unfreed. Never seen this before.

It's because you have memory corruption. Then heaptrc cannot give accurate statistics.

Show quoted text 17 lines
I will test with valgrind this afternoon to see if I can get some wiser from it. BTW, for those interested, I ported some code that allows bitmapped freetype fonts be used in OpenGL this works a lot simpler than using the freetype support from fcl-image. If you wish you can find the code here: http://scandraid.svn.sourceforge.net/viewvc/scandraid/src/branches/font/ Darius > bitmappedglfont Marked memory at $0A5AF068 invalid Wrong signature $9BC362D6 instead of D1853A22 $0040CFBB $00407D08 $00401948 KEYPRESSED, line 80 of BitmappedGLFont.pas $0984E054 $0984D5DE $7E418734 $7E418816 $7E42A013 $7E42A039

This shows that you have memory corruption somewhere ("Marked memory at ... invalid").

Jonas

Reply by email

Darius Blaszyk
to Jonas Maebe
Jonas Maebe wrote 26 lines
On 10 Apr 2011, at 15:02, Darius Blaszyk wrote: > You're right that there seems to be a memleak somewhere, but it's something strange, heaptrc reports 1 unfreed block and 0bytes unfreed. Never seen this before. It's because you have memory corruption. Then heaptrc cannot give accurate statistics. > I will test with valgrind this afternoon to see if I can get some wiser from it. > BTW, for those interested, I ported some code that allows bitmapped freetype fonts be used in OpenGL this works a lot simpler than using the freetype support from fcl-image. If you wish you can find the code here: http://scandraid.svn.sourceforge.net/viewvc/scandraid/src/branches/font/ > > Darius > >> bitmappedglfont > Marked memory at $0A5AF068 invalid > Wrong signature $9BC362D6 instead of D1853A22 > $0040CFBB > $00407D08 > $00401948 KEYPRESSED, line 80 of BitmappedGLFont.pas > $0984E054 > $0984D5DE > $7E418734 > $7E418816 > $7E42A013 > $7E42A039 This shows that you have memory corruption somewhere ("Marked memory at ... invalid").

Valgrind made it possible to solve the memory corruption bug. It appeared that I just did not reserve enough for the textures. After solving this, the SIGSEGV also disappeared like you predicted. Thanks Jonas!

Darius

Reply by email