readlink, getcwd memory leaks

readlink, getcwd memory leaks

[Kevin Ryde]

[-- Attachment #1: Type: text/plain, Size: 325 bytes --]

        * filesys.c (scm_getcwd, scm_readlink): Avoid memory leak on errors.

Unbounded growth can be seen with

	(while #t (false-if-exception (readlink "nosuchfile")))

and

	(mkdir "somedir")
	(chdir "somedir")
	(rmdir "../somedir")
	(while #t (false-if-exception (getcwd)))

This will be for the 1.6 branch too I think.


[-- Attachment #2: filesys.c.leak.diff --]
[-- Type: text/plain, Size: 999 bytes --]

--- filesys.c.~1.119.~	2003-05-30 08:40:07.000000000 +1000
+++ filesys.c	2004-03-25 14:16:28.000000000 +1000
@@ -1,4 +1,4 @@
-/* Copyright (C) 1996,1997,1998,1999,2000,2001, 2002 Free Software Foundation, Inc.
+/* Copyright (C) 1996,1997,1998,1999,2000,2001, 2002, 2004 Free Software Foundation, Inc.
  * 
  * This library is free software; you can redistribute it and/or
  * modify it under the terms of the GNU Lesser General Public
@@ -929,7 +929,12 @@
       wd = scm_malloc (size);
     }
   if (rv == 0)
-    SCM_SYSERROR;
+    {
+      int save_errno = errno;
+      free (wd);
+      errno = save_errno;
+      SCM_SYSERROR;
+    }
   result = scm_mem2string (wd, strlen (wd));
   free (wd);
   return result;
@@ -1349,7 +1354,12 @@
       buf = scm_malloc (size);
     }
   if (rv == -1)
-    SCM_SYSERROR;
+    {
+      int save_errno = errno;
+      free (buf);
+      errno = save_errno;
+      SCM_SYSERROR;
+    }
   result = scm_mem2string (buf, rv);
   free (buf);
   return result;

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: readlink, getcwd memory leaks

[Marius Vollmer]

Kevin Ryde <user42@zip.com.au> writes:

>         * filesys.c (scm_getcwd, scm_readlink): Avoid memory leak on errors.
>
> This will be for the 1.6 branch too I think.

Yes, please.

(There still will be a memory leak when scm_mem2string throws, but that
 is very unlikely...)

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: readlink, getcwd memory leaks

[Kevin Ryde]

Marius Vollmer <mvo@zagadka.de> writes:
>
> (There still will be a memory leak when scm_mem2string throws, but that
>  is very unlikely...)

I was thinking about that after Dirk changed scm_gethostbyname.  Looks
like a lot of potential places like that, and no fun to try to tighten
them up :-(.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: readlink, getcwd memory leaks

[Marius Vollmer]

Kevin Ryde <user42@zip.com.au> writes:

> Marius Vollmer <mvo@zagadka.de> writes:
>>
>> (There still will be a memory leak when scm_mem2string throws, but that
>>  is very unlikely...)
>
> I was thinking about that after Dirk changed scm_gethostbyname.  Looks
> like a lot of potential places like that, and no fun to try to tighten
> them up :-(.

Yes.  Maybe we should just disallow out-of-memory throws.  There is no
real point for them: Guile likely can't continue anyway.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: readlink, getcwd memory leaks

[Dirk Herrmann]

Marius Vollmer wrote:

>  Kevin Ryde <user42@zip.com.au> writes:
>
> > Marius Vollmer <mvo@zagadka.de> writes:
> >
> >> (There still will be a memory leak when scm_mem2string throws,
> >> but that is very unlikely...)
> >
> > I was thinking about that after Dirk changed scm_gethostbyname.
> > Looks like a lot of potential places like that, and no fun to try
> > to tighten them up :-(.
>
>
>  Yes. Maybe we should just disallow out-of-memory throws. There is
>  no real point for them: Guile likely can't continue anyway.

Sounds good to me. Let's make it official policy and modify 
scm_memory_error to abort. (scm_gethostname could then be simplified 
again...)

Best regards,
Dirk



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: readlink, getcwd memory leaks

[Rob Browning]

Dirk Herrmann <dirk@dirk-herrmanns-seiten.de> writes:

> Marius Vollmer wrote:
>
>>  Kevin Ryde <user42@zip.com.au> writes:
>>
>>  Yes. Maybe we should just disallow out-of-memory throws. There is
>>  no real point for them: Guile likely can't continue anyway.
>
> Sounds good to me. Let's make it official policy and modify
> scm_memory_error to abort. (scm_gethostname could then be simplified
> again...)

That would preclude any kind of "release and retry" catch handler.  Do
we care about that?  (I'm not saying we do, just wondering.)

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: readlink, getcwd memory leaks

[Marius Vollmer]

Rob Browning <rlb@defaultvalue.org> writes:

>> Sounds good to me. Let's make it official policy and modify
>> scm_memory_error to abort. (scm_gethostname could then be simplified
>> again...)
>
> That would preclude any kind of "release and retry" catch handler.  Do
> we care about that?  (I'm not saying we do, just wondering.)

Yes, just aborting is maybe a bit inflexible.  (I think we have
discussed this previously.)  We could allow the registration of
handlers (written in C) for out-of-memory and the default handler
could print a warning, wait a bit, and then retry, backing off
exponentially.  Or something.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: readlink, getcwd memory leaks

[Stephen Compall]

Marius Vollmer <mvo@zagadka.de> writes:

> Yes, just aborting is maybe a bit inflexible.  (I think we have
> discussed this previously.)  We could allow the registration of
> handlers (written in C) for out-of-memory and the default handler
> could print a warning, wait a bit, and then retry, backing off
> exponentially.  Or something.

All sorts of room for creativity here, I guess, but if that's too much
I think an excellent case would be to exec a configurable program of
your choice, or abort if that fails.  In the common case, it is the
Guile-using program itself that has eaten too much memory, so exec
should clear that, and the exec'd program can do whatever complicated
error-handling you like (e.g. pop up a window explaining the problem.
You probably won't be able to load up a GUI library or widgets in the
same program if you ran out of memory :).

--
Stephen Compall or s11 or sirian

The system was down for backups from 5am to 10am last Saturday.

explosion TWA KGB UOP Rule Psix import Kh-11 bce NSA UNSCOM Lon
Horiuchi defense information warfare STARLAN Honduras fraud


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: readlink, getcwd memory leaks

[Kevin Ryde]

Actually, one easy approach for some of these mallocing things might
be to hold the blocks in an SCM, rather than registering a frame
handler thingie.  If there's an error throw then the gc will pick up
the pieces.

scm_make_string or whatever does the trick for malloc, is there some
sort of scm_resize_string hiding?  Just for internal use (at least
initially).


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel