Folks,
there is a serious memory leak in the gpc-20010623. The full story:
The gpc version on the SuSE 7.2 CD is broken. The installation from source is smooth. The results of the test codes are excellent only 8 fails. Then comes the problem. I wrote a code. It compiles and starts to run. But after a few minutes crashes out with segmentation fault. The "top" suggests that the size of the task grows linearly with the time. In about 10 minutes the size is 5 times bigger. Then I tried the same code on under IRIX 6.5 with gpc-20010623. The output is crippled due to a bug but it shows the same symptom. It just keep on growing. The same code with the good-old gpc 2.0 runs for more than 20 hours without any problem. The memory management in the latest distribution must be fundamentally wrong.
Have any of you experienced the same problem? Is there a compiler switch to force a more strict memory management mode?
Help me please!
miklos
In article Pine.SGI.4.33.0109241727020.103754-100000@pugh.bip.bham.ac.uk, Miklos Cserzo miklos@pugh.bip.bham.ac.uk writes
there is a serious memory leak in the gpc-20010623. The full story:
The gpc version on the SuSE 7.2 CD is broken. The installation from source is smooth. The results of the test codes are excellent only 8 fails. Then comes the problem. I wrote a code. It compiles and starts to run. But after a few minutes crashes out with segmentation fault. The "top" suggests that the size of the task grows linearly with the time. In about 10 minutes the size is 5 times bigger. Then I tried the same code on under IRIX 6.5 with gpc-20010623. The output is crippled due to a bug but it shows the same symptom. It just keep on growing. The same code with the good-old gpc 2.0 runs for more than 20 hours without any problem. The memory management in the latest distribution must be fundamentally wrong.
Have any of you experienced the same problem? Is there a compiler switch to force a more strict memory management mode?
There certainly was a serious memory leak problem in the run time system that gave us a lot of grief, however it was fixed by Frank in late May so it isn't that one you are seeing. We certainly aren't currently seeing any memory leaks in applications that run for several days at a time. You will need to provide some more information to help in isolating the problem. Can you provide a reasonable size test program that demonstrates the problem?
If you look at the thread in the archive, that ran intermittently for about 6 months, titled "Re: memory Use Problem" you will find a number of helpful suggestions for getting to grips with the problem. For us the most useful suggestion was from Russ Whitaker as follows:
"Try info glibc. There's a node called "Allocation Debugging" with 4 sub-nodes.
Don't know about earlier releases, but it is in glibc-2.2.2 release."
Good luck.
On Mon, 24 Sep 2001, Martin Liddle wrote:
There certainly was a serious memory leak problem in the run time system that gave us a lot of grief, however it was fixed by Frank in late May so it isn't that one you are seeing. We certainly aren't currently seeing any memory leaks in applications that run for several days at a time. You will need to provide some more information to help in isolating the problem. Can you provide a reasonable size test program that demonstrates the problem?
My code is a bit complex I rather wouldn't post it unless it's unavoidable. All I can say now: there is no dynamic memory allocation involved nor pointers nor anything notoriously easy to make it wrong. Only very basic straight Pascal.
Again, the bug is platform independent. I can reproduce it on IRIX and SuSE as well with the latest gpc-snapshot. While the same code is stable on IRIX gpc 2.0.
miklos
In article Pine.SGI.4.33.0109242140230.155863-100000@pugh.bip.bham.ac.uk, Miklos Cserzo miklos@pugh.bip.bham.ac.uk writes
There certainly was a serious memory leak problem in the run time system that gave us a lot of grief, however it was fixed by Frank in late May so it isn't that one you are seeing. We certainly aren't currently seeing any memory leaks in applications that run for several days at a time. You will need to provide some more information to help in isolating the problem. Can you provide a reasonable size test program that demonstrates the problem?
My code is a bit complex I rather wouldn't post it unless it's unavoidable. All I can say now: there is no dynamic memory allocation involved nor pointers nor anything notoriously easy to make it wrong. Only very basic straight Pascal.
I don't doubt you are seeing a problem and please don't post anything large. However for this problem to be found you are going to have to do a bit of work. Try hacking the code down to isolate where the problem occurs.
Not everybody is seeing your problem and you will have to provide some clues.
Miklos Cserzo wrote:
On Mon, 24 Sep 2001, Martin Liddle wrote:
There certainly was a serious memory leak problem in the run time system that gave us a lot of grief, however it was fixed by Frank in late May so it isn't that one you are seeing. We certainly aren't currently seeing any memory leaks in applications that run for several days at a time. You will need to provide some more information to help in isolating the problem. Can you provide a reasonable size test program that demonstrates the problem?
My code is a bit complex I rather wouldn't post it unless it's unavoidable. All I can say now: there is no dynamic memory allocation involved nor pointers nor anything notoriously easy to make it wrong. Only very basic straight Pascal.
There is a known problem. Some operations (esp. string concatenation) need temporary storage (on the stack) which isn't freed immediately, so it will accumulate in loops. A trivial example follows.
program Foo;
var s: String (100) = '';
begin repeat s := s + '' until False end.
I think we know the cause of the problem (alloca_string if anyone cares) and therefore can fix it soon.
The only know work-around for know is to move the loop body into a subroutine. That's not nice, but if it works, you can at least be quite sure it's this problem you see.
Frank
On Tue, 25 Sep 2001, Frank Heckenbach wrote:
Miklos Cserzo wrote:
On Mon, 24 Sep 2001, Martin Liddle wrote:
There certainly was a serious memory leak problem in the run time system that gave us a lot of grief, however it was fixed by Frank in late May so it isn't that one you are seeing. We certainly aren't currently seeing any memory leaks in applications that run for several days at a time. You will need to provide some more information to help in isolating the problem. Can you provide a reasonable size test program that demonstrates the problem?
My code is a bit complex I rather wouldn't post it unless it's unavoidable. All I can say now: there is no dynamic memory allocation involved nor pointers nor anything notoriously easy to make it wrong. Only very basic straight Pascal.
I have similiar (?) problem with GPC version 20010623. It's also platform independant - it appears with versions built for Linux on i386 and Solaris on Sparc. The same code that consumes not more that 5 MB on Solaris/i386 (GPC 20010121) while working now gets more that 30 MB of memory, growing linearly.
There is a known problem. Some operations (esp. string concatenation) need temporary storage (on the stack) which isn't freed immediately, so it will accumulate in loops. A trivial example follows. I think we know the cause of the problem (alloca_string if anyone cares) and therefore can fix it soon.
In my case there is not much string manipulation staff, but a lot of dynamic allocation ... Still I'm very anxious to check whether it can help me when you manage to fix it.
Regards, Adam Naumowicz
-------------------------------------- WWW: http://math.uwb.edu.pl/~adamn/ --------------------------------------
On Tue, 25 Sep 2001, Frank Heckenbach wrote:
There is a known problem. Some operations (esp. string concatenation) need temporary storage (on the stack) which isn't freed immediately, so it will accumulate in loops. A trivial example follows.
program Foo;
var s: String (100) = '';
begin repeat s := s + '' until False end.
I think we know the cause of the problem (alloca_string if anyone cares) and therefore can fix it soon.
The only know work-around for know is to move the loop body into a subroutine. That's not nice, but if it works, you can at least be quite sure it's this problem you see.
That was part of my problem. If I modify my code in this style:
program Foo;
var s: String (100) = '';
procedure loop;
begin s := s + '' end;
begin repeat loop; until False end.
it is not growing that fast any more. (In fact, for this particular example it is not growing at all.) For that I had to move all the string operations behind a procedure (i.e. concat, writestr and readstr). However it is still growing a bit. Could that caused by the calls of the "random" function in the program?
Cheers,
miklos
Adam Naumowicz wrote:
I have similiar (?) problem with GPC version 20010623. It's also platform independant - it appears with versions built for Linux on i386 and Solaris on Sparc. The same code that consumes not more that 5 MB on Solaris/i386 (GPC 20010121) while working now gets more that 30 MB of memory, growing linearly.
There is a known problem. Some operations (esp. string concatenation) need temporary storage (on the stack) which isn't freed immediately, so it will accumulate in loops. A trivial example follows. I think we know the cause of the problem (alloca_string if anyone cares) and therefore can fix it soon.
In my case there is not much string manipulation staff, but a lot of dynamic allocation ... Still I'm very anxious to check whether it can help me when you manage to fix it.
The problem I was talking about is about string operations (in particular, Concat/+, ParamStr and CString2String), not dynamic allocation. If there are leaks with dynamic allocation, we'd have to debug them separately because I'm not aware of any current bugs in this area.
Frank
-
Adam Naumowicz -
Frank Heckenbach -
Martin Liddle -
Miklos Cserzo