[fpc-devel] ReallocMem with CMem
Hi, Shouldn't ReallocMem in CMem zero the newly allocated bytes ? Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] ReallocMem with CMem
Op Wed, 8 Mar 2006, schreef Micha Nelissen: Hi, Shouldn't ReallocMem in CMem zero the newly allocated bytes ? No, it is the responsibility of the programmer. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] ReallocMem with CMem
On Wed, 8 Mar 2006 18:10:38 +0100 (CET) Daniël Mantione [EMAIL PROTECTED] wrote: Op Wed, 8 Mar 2006, schreef Micha Nelissen: Shouldn't ReallocMem in CMem zero the newly allocated bytes ? No, it is the responsibility of the programmer. Nope. At least the compiler depends on it being zeroed. The FPC heap manager zeroes it, as well. Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] ReallocMem with CMem
On 8 mrt 2006, at 18:19, Micha Nelissen wrote: Shouldn't ReallocMem in CMem zero the newly allocated bytes ? No, it is the responsibility of the programmer. Nope. At least the compiler depends on it being zeroed. Where? It's a bug if it does. The FPC heap manager zeroes it, as well. It shouldn't need to do that. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] ReallocMem with CMem
On Wed, 8 Mar 2006 18:19:40 +0100 Micha Nelissen [EMAIL PROTECTED] wrote: On Wed, 8 Mar 2006 18:10:38 +0100 (CET) Daniël Mantione [EMAIL PROTECTED] wrote: Op Wed, 8 Mar 2006, schreef Micha Nelissen: Shouldn't ReallocMem in CMem zero the newly allocated bytes ? No, it is the responsibility of the programmer. Good. Nope. At least the compiler depends on it being zeroed. The FPC heap manager zeroes it, as well. Not under linux. Are you sure? Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] ReallocMem with CMem
Op Wed, 8 Mar 2006, schreef Micha Nelissen: On Wed, 8 Mar 2006 18:10:38 +0100 (CET) Daniël Mantione [EMAIL PROTECTED] wrote: Op Wed, 8 Mar 2006, schreef Micha Nelissen: Shouldn't ReallocMem in CMem zero the newly allocated bytes ? No, it is the responsibility of the programmer. Nope. At least the compiler depends on it being zeroed. The FPC heap manager zeroes it, as well. That is behaviour contrary to the documentation. Our documentation: ReAllocMem resizes the memory pointed to by P so it has size Size. The value of P may change during this operation. The contents of the memory pointed to by P (if any) will be copied to the new location, but may be truncated if the newly allocated memory block is smaller in size. If a larger block is allocated, only the used memory is initialized, extra memory will not be zeroed out. Note that P may be nil, in that case the behaviour of ReAllocMem is equivalent to Getmem. Delphi documentation: The ReallocMem procedure changes the storage size of an existing block of storage. The size may be smaller or bigger. If smaller, then the existing storage is effectively truncated, the remainder being released. If larger, the storage is extended. Or a new block is allocated if necessary. In either case, the It is better to use New for this existing storage block data is preserved, and the new part is unitialised. There is a good reason that the memory should not be initialised; you can allocate large amounts of memory in advance. This memory is not actually allocated by the OS until you use it. As soon as you initialize the memory, it gets allocated immediately. If the FPC heap manager initialises the memory, that functionality should be removed. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Bug in threads
Hello, I've recompiled a Kylix app
into freepascal that uses threads and now with FPC I've noticed that
the memory used by my program is growing until it gets all of the
system memory.
So I've made a simple app to test what was wrong, and this app shows
that the problem is with thread allocation. Each allocated thread is
getting more or less 2052 kb from memory and is never putting this back.
The program I wrote to test is this that follows, it creates 10 threads
and then shows memory utilized ( by looking at file /proc/PID/status ),
then waits you to press enter, it will terminate all threads and show
the
memory again. When you press enter again it will alloc + 10 threads and
so on.
I've seen on the bug-list of freepascal that anybody already registered
this as a bug, I want that somebody give me a direction for how to
begin to resolve this problem. I already browsed the on-line cvs and
looked at some of threads units on FPC source. But up to now I couldn't
find anything.
Thanks for any help
program project1;
{$mode objfpc}{$H+}
uses
cmem, cthreads, Libc, Classes, SysUtils
{ add your units here };
type
TMyThread = class (TThread)
private
public
procedure execute(); override;
end;
const MAXTHREADS = 9;
var threads : array [0..MAXTHREADS] of TMyThread;
i : integer;
s : string;
f : TextFile;
pid : integer;
procedure TMyThread.Execute();
begin
end;
begin
while (true) do
begin
for i := 0 to MAXTHREADS do
begin
threads[i] := TMyThread.Create(false);
end;
pid := getPid();
AssignFile(f, '/proc/'+IntToStr(pid)+'/status');
Reset(f);
repeat
ReadLn(f, s);
until (Copy(s,1,6)='VmSize');
Write(IntToStr(MAXTHREADS)+' threads initialized.');
WriteLn(s);
ReadLn();
for i := 0 to MAXTHREADS do
begin
threads[i].FreeOnTerminate := true;
threads[i].Terminate;
threads[i].Free;
end;
write('threads finalized.');
Reset(f);
repeat
ReadLn(f, s);
until (Copy(s,1,6)='VmSize');
writeln(s);
writeln('');
s := '';
writeln('Press ENTER to try again');
readln(s);
if (s'') then break;
end;
end.
___
Yahoo! Acesso Grátis - Internet rápida e grátis. Instale o discador agora!
http://br.acesso.yahoo.com
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] ReallocMem with CMem
On Wed, 8 Mar 2006 18:33:53 +0100 Mattias Gaertner [EMAIL PROTECTED] wrote: Nope. At least the compiler depends on it being zeroed. The FPC heap manager zeroes it, as well. Not under linux. Are you sure? Hmm, that was changed then and the compiler was fixed; probably due to me mentioning it on IRC sometime ago, also :-). The name has 'alloc' in it, so maybe that's why I keep getting confused, ResizeMem or so would be more appropriate. Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] ReallocMem with CMem
On Wed, 8 Mar 2006 19:10:55 +0100 Mattias Gaertner [EMAIL PROTECTED] wrote: On Wed, 8 Mar 2006 19:01:11 +0100 Micha Nelissen [EMAIL PROTECTED] wrote: Hmm, that was changed then and the compiler was fixed; probably due to me mentioning it on IRC sometime ago, also :-). The name has 'alloc' in it, so maybe that's why I keep getting confused, ResizeMem or so would be more appropriate. What has 'alloc' to do with cleaning/zeroing? It is *the* difference between GetMem and AllocMem. Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] ReallocMem with CMem
On Wed, 8 Mar 2006, Micha Nelissen wrote: On Wed, 8 Mar 2006 19:10:55 +0100 Mattias Gaertner [EMAIL PROTECTED] wrote: On Wed, 8 Mar 2006 19:01:11 +0100 Micha Nelissen [EMAIL PROTECTED] wrote: Hmm, that was changed then and the compiler was fixed; probably due to me mentioning it on IRC sometime ago, also :-). The name has 'alloc' in it, so maybe that's why I keep getting confused, ResizeMem or so would be more appropriate. What has 'alloc' to do with cleaning/zeroing? It is *the* difference between GetMem and AllocMem. Not in FPC. Reallocmem just resizes. No zeroing is done, as already explained by Jonas and Daniel. Only classes/objects that are allocated on the heap are zeroed. Plain memory is not touched in any way. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] full implementation of a memory based dataset?
On Wed, 8 Mar 2006, Dale Welch wrote: does anyone know of a full implementation of a memory based dataset? tmemdataset and sdfdataset both do not implement the canmodify property. But they are both read-write. I'll see about fixing the CanModify property, though. i would like a memory based dataset which allows me to post records. preferably one which will be a full implementation and therefor work with lazarus. One that has documentation always helps. :-) RxLib has a TrxMemoryDataset which should work as-is with FPC. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] ReallocMem with CMem
On 8 mrt 2006, at 20:34, Michael Van Canneyt wrote: What has 'alloc' to do with cleaning/zeroing? It is *the* difference between GetMem and AllocMem. Not in FPC. Reallocmem just resizes. No zeroing is done, as already explained by Jonas and Daniel. Yes, but allocmem() does zero the allocated memory (although our documentation at http://www.freepascal.org/docs-html/rtl/system/ allocmem.html claims it's the same as getmem, that's not true -- I guess because in Delphi it also zeroes the allocated memory with allocmem). Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] ReallocMem with CMem
On Wed, 8 Mar 2006, Jonas Maebe wrote: On 8 mrt 2006, at 20:34, Michael Van Canneyt wrote: What has 'alloc' to do with cleaning/zeroing? It is *the* difference between GetMem and AllocMem. Not in FPC. Reallocmem just resizes. No zeroing is done, as already explained by Jonas and Daniel. Yes, but allocmem() does zero the allocated memory (although our documentation at http://www.freepascal.org/docs-html/rtl/system/ allocmem.html claims it's the same as getmem, that's not true -- I guess because in Delphi it also zeroes the allocated memory with allocmem). I'll change the docs accordingly. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Bug in threads
Complementing my last post about threads, this is the log file generated by valgrind running this program. ==3968== Memcheck, a memory error detector. ==3968== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al. ==3968== Using LibVEX rev 1367, a library for dynamic binary translation. ==3968== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP. ==3968== Using valgrind-3.0.1, a dynamic binary instrumentation framework. ==3968== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al. ==3968== ==3968== My PID = 3968, parent PID = 6992. Prog and args are: ==3968==project1 --3968-- --3968-- Valgrind library directory: /usr/local/lib/valgrind --3968-- Command line --3968--project1 --3968-- Startup, with flags: --3968----leak-check=full --3968---v --3968----show-reachable=yes --3968----leak-resolution=high --3968----log-file=valgrind.log --3968-- Contents of /proc/version: --3968-- Linux version 2.6.11.4-21.10-smp ([EMAIL PROTECTED]) (gcc version 3.3.5 20050117 (prerelease) (SUSE Linux)) #1 SMP Tue Nov 29 14:32:49 UTC 2005 --3968-- Reading syms from /tmp/fpctest/project1 (0x8048000) --3968-- Reading syms from /lib/ld-2.3.4.so (0x1B8E4000) --3968-- Reading syms from /usr/local/lib/valgrind/stage2 (0xB000) --3968-- Reading suppressions file: /usr/local/lib/valgrind/default.supp ==3968== --3968-- Reading syms from /usr/local/lib/valgrind/vg_preload_core.so (0x1B8FC000) --3968-- Reading syms from /usr/local/lib/valgrind/vgpreload_memcheck.so (0x1B8FF000) --3968-- REDIR: 0x1B8F6B60 (index) redirected to 0x1B902170 (index) --3968-- REDIR: 0x1B8F6D00 (strlen) redirected to 0x1B9023B0 (strlen) --3968-- Reading syms from /lib/tls/libpthread.so.0 (0x1B91E000) --3968-- Reading syms from /lib/libdl.so.2 (0x1B93) --3968-- Reading syms from /lib/libcrypt.so.1 (0x1B934000) --3968-- Reading syms from /lib/tls/libc.so.6 (0x1B966000) --3968-- REDIR: 0x1B8E47A0 (_dl_sysinfo_int80) redirected to 0xB0022343 (???) --3968-- REDIR: 0x1B9CDC90 (rindex) redirected to 0x1B902050 (rindex) --3968-- REDIR: 0x1B9CA520 (malloc) redirected to 0x1B90082A (malloc) --3968-- REDIR: 0x1B9C8640 (free) redirected to 0x1B901353 (free) --3968-- REDIR: 0x1B9CB3C0 (calloc) redirected to 0x1B901B0F (calloc) --3968-- REDIR: 0x1B9CD1D0 (index) redirected to 0x1B902140 (index) --3968-- REDIR: 0x1B8F70D0 (stpcpy) redirected to 0x1B902940 (stpcpy) --3968-- Reading syms from /lib/libgcc_s.so.1 (0x1CFE5000) --3968--object doesn't have a symbol table --3968-- REDIR: 0x1B9CD8D0 (strlen) redirected to 0x1B902390 (strlen) ==3968== ==3968== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 24 from 3) --3968-- --3968-- supp:3 index-not-intercepted-early-enough-HACK-3 --3968-- supp: 19 dl_relocate_object --3968-- supp:2 strlen/*dl_map_object*(Cond) ==3968== malloc/free: in use at exit: 2896 bytes in 37 blocks. ==3968== malloc/free: 316 allocs, 279 frees, 28779 bytes allocated. ==3968== ==3968== searching for pointers to 37 not-freed blocks. ==3968== checked 63642440 bytes. ==3968== ==3968== 16 bytes in 1 blocks are still reachable in loss record 1 of 8 ==3968==at 0x1B901B95: calloc (vg_replace_malloc.c:279) ==3968==by 0x1B931239: _dlerror_run (in /lib/libdl.so.2) ==3968==by 0x1B930D30: dlopen@@GLIBC_2.1 (in /lib/libdl.so.2) ==3968==by 0x8060C82: (within /tmp/fpctest/project1) ==3968==by 0x8061BDA: (within /tmp/fpctest/project1) ==3968==by 0x805A1BB: SYSTEM_SETTHREADMANAGER$TTHREADMANAGER$$BOOLEAN (in /tmp/fpctest/project1) ==3968==by 0x8061D6C: CTHREADS_SETCTHREADMANAGER (in /tmp/fpctest/project1) ==3968==by 0x8061DF1: CTHREADS_init (in /tmp/fpctest/project1) ==3968==by 0x8056C4C: fpc_initializeunits (in /tmp/fpctest/project1) ==3968==by 0x8048B29: main (project1.pas:30) ==3968==by 0x8048A3C: (within /tmp/fpctest/project1) ==3968== ==3968== ==3968== 19 bytes in 1 blocks are still reachable in loss record 2 of 8 ==3968==at 0x1B9008A9: malloc (vg_replace_malloc.c:149) ==3968==by 0x1B8ECDF0: _dl_new_object (in /lib/ld-2.3.4.so) ==3968==by 0x1B8E942D: _dl_map_object_from_fd (in /lib/ld-2.3.4.so) ==3968==by 0x1B8EB050: _dl_map_object (in /lib/ld-2.3.4.so) ==3968==by 0x1BA5223D: dl_open_worker (in /lib/tls/libc.so.6) ==3968==by 0x1B8F1185: _dl_catch_error (in /lib/ld-2.3.4.so) ==3968==by 0x1BA51BDF: _dl_open (in /lib/tls/libc.so.6) ==3968==by 0x1BA53D4C: do_dlopen (in /lib/tls/libc.so.6) ==3968==by 0x1B8F1185: _dl_catch_error (in /lib/ld-2.3.4.so) ==3968==by 0x1BA53BD4: dlerror_run (in /lib/tls/libc.so.6) ==3968==by 0x1BA53CFA: __libc_dlopen_mode (in /lib/tls/libc.so.6) ==3968==by 0x1B929F47: pthread_cancel_init (in /lib/tls/libpthread.so.0) ==3968== ==3968== ==3968== 19 bytes in 1 blocks are still reachable in loss record 3 of 8 ==3968==at 0x1B9008A9: malloc (vg_replace_malloc.c:149) ==3968==by 0x1B8EB4D1: _dl_map_object (in /lib/ld-2.3.4.so) ==3968==by 0x1BA5223D:
Re: [fpc-devel] FPC 2.0.0 vs FPC 2.0.2 (div by zero)
(Second send, it seems that mails from my old email address do not reach fpc lists) Den Jean wrote: Hi, I have a strange problem. My Qt4 demo program worked fine with FPC 2.0.0, but crashes (div by zero) with FPC 2.0.2. Debugging shows that indeed a div by zero is done within the Qt4 lib. However with FPC 2.0.0 or using C++ code the library isn't bothered with the div by zero. When I use FPC 2.0.2 however it is. Maybe it was FPC 2.0.0 bug (that was fixed in the meantime) that caused this SIGFPE inside qt to be ignored ? AFAIK it was always the intention of FPC that if used library causes a signal like SIGFPE, this signal *will not be ignored* and will cause our program to fail with some exception. Maybe you can workaround this with Set8087CW, just like it has to be workarounded for OpenGL under Windows (see [http://www.freepascal.org/bugs/showrec.php3?ID=3955]). Just add Set8087CW($133F); at the beginning of your program (or even right inside qt unit initialization) and see if it helps. (Note that I'm writing this without any knowledge of qt or your testcase --- I just thought that it may be helpful, sorry if it's not relevant :) ). Michalis ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
