Here it's the patch about the memory leak.
From 888f31dfedc1292cff9fce2d2ef20f986c2fb669 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Miguel=20=C3=81ngel=20Arruga=20Vivas?=
Date: Mon, 12 Oct 2020 13:25:25 +0200
Subject: [PATCH 1/2] Fix memory leak after an error.
* libguile/i
GNU_LOCALE_API is not defined) I found something that seems to be a
memory leak, but I don't know where to test it---I don't know which
systems don't define it, nothing I have running right now at least.
The order of the patches is the inverse of the mail, as I wrote the
first befor
On Sat 12 Apr 2014 08:59, Dmitry Bogatov writes:
> * Dmitry Bogatov [2014-04-10 20:52:43+0400]
>> > > + {
>> > > +free (nargv);
>> > > return 0L;
>> > > + }
>> > > else
>> > >nargv[nargi++] = narg;
>> > I don
, Dmitry Bogatov ,
Free Software supporter, esperantisto and netiquette guardian.
git://kaction.name/rc-files.git
GPG: 54B7F00D
>From d3ce0b807aa624a9316e2b7da024f030233dae74 Mon Sep 17 00:00:00 2001
From: Dmitry Bogatov
Date: Thu, 10 Apr 2014 09:23:28 +0400
Subject: [PATCH] Fix memo
* dsm...@roadrunner.com [2014-04-10 12:36:48-0400]
> > + {
> > + free (nargv);
> > return 0L;
> > + }
> > else
> > nargv[nargi++] = narg;
> I don't understand this. In both cases, free() will be called with an
> argument of 0, which does not
kact...@gnu.org wrote:
> From: Dmitry Bogatov
>
> Signed-off-by: Dmitry Bogatov
> ---
> libguile/script.c | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/libguile/script.c b/libguile/script.c
> index 052ab8d..7b737f7 100644
> --- a/libguile/script.c
> +++
From: Dmitry Bogatov
Signed-off-by: Dmitry Bogatov
---
libguile/script.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/libguile/script.c b/libguile/script.c
index 052ab8d..7b737f7 100644
--- a/libguile/script.c
+++ b/libguile/script.c
@@ -247,7 +247,10 @@ script_rea
Hi Stefan,
Stefan Israelsson Tampe skribis:
> Regarding the observed leaks in guile. A question is if this is due to some
> kind of memory fragmentation more then
> a pure memory leak. In the observed bug where in constructing and droping
> threads, one can see that memory leaks
Hi,
Regarding the observed leaks in guile. A question is if this is due to some
kind of memory fragmentation more then
a pure memory leak. In the observed bug where in constructing and droping
threads, one can see that memory leaks dramatically
and 2Gig is consumed after about 2000 constructed
On Thu 02 Sep 2010 05:49, l...@gnu.org (Ludovic Courtès) writes:
> Basically ‘force’ was leaking memory because it uses ‘lock-mutex’, which
> was the culprit (!).
You are a superhero, Dr. Courtès!!
A
--
http://wingolog.org/
Hey Ludovic,
On Thu, Sep 2, 2010 at 8:49 AM, Ludovic Courtès wrote:
> I believe this patch fixes the problem:
>
> http://git.sv.gnu.org/cgit/guile.git/commit/?id=f57fdf07d6374028f35bcb1ee748a94022deda6d
>
> Basically ‘force’ was leaking memory because it uses ‘lock-mutex’, which
> was the culpr
> "kr" == Kevin Ryde <[EMAIL PROTECTED]> writes:
>> Am I needlessly worrying about this?
kr> Yep. When there are no more pointers to an object, it's reaped.
D'oh - forgive the mental lapse. GC reaps objects no longer pointed
*to* - I knew that. The other bit I was missing was tha
"Michael J. Barillier" <[EMAIL PROTECTED]> writes:
>
> Am I needlessly worrying about this?
Yep. When there are no more pointers to an object, it's reaped.
> Will the list returned from scm_c_eval_string be garbage-collected,
Yep.
(I'd thought a couple of times it'd be nice to be able to expli
I'd appreciate someone confirming that scm_c_eval_string doesn't leak
memory. From strports.c:
,
| SCM
| scm_c_eval_string (const char *expr)
| {
| return scm_eval_string (scm_makfrom0str (expr));
| }
`
(NB: This is from guile-1.6.7 - the CVS version has scm_makfrom0str
d
14 matches
Mail list logo
