port initialization?

port initialization?

[Han-Wen]

Just looking at some weird valgrind error here,  ...

what about
  
  z = scm_cell (scm_tc16_strport, 0);
  SCM_DEFER_INTS;
  pt = scm_add_to_port_table (z);
  SCM_SET_CELL_TYPE (z, scm_tc16_strport | modes);
  SCM_SETPTAB_ENTRY (z, pt);
  SCM_SETSTREAM (z, SCM_UNPACK (str));

This looks like fishy code to me. When scm_add_to_port_table triggers
GC then it will see the (scm_tc16_strport, 0) cell, which is (or
should be) invalid.

Why not

    scm_t_port * 
    scm_add_to_port_table ()
    {
	scm_t_port *p = gc_malloc( sizeof (scm_t_port));
	p->port = SCM_EOL;
    	...
    }


    {
	scm_t_port *newport =  scm_add_to_port_table ();
	SCM port = scm_cell (scm_tc16_port, newport);
	newport->port = port;
		      ..
    }

Comments? 



--	
Han-Wen Nienhuys   |   hanwen@cs.uu.nl   |   http://www.cs.uu.nl/~hanwen 

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

Re: port initialization?

[Marius Vollmer]

Han-Wen <hanwen@cs.uu.nl> writes:

> what about
>   
>   z = scm_cell (scm_tc16_strport, 0);
>   SCM_DEFER_INTS;
>   pt = scm_add_to_port_table (z);
>   SCM_SET_CELL_TYPE (z, scm_tc16_strport | modes);
>   SCM_SETPTAB_ENTRY (z, pt);
>   SCM_SETSTREAM (z, SCM_UNPACK (str));
> 
> This looks like fishy code to me. When scm_add_to_port_table triggers
> GC then it will see the (scm_tc16_strport, 0) cell, which is (or
> should be) invalid.

Yes, but the GC will not notice since "z" still refers to it and
therefore the port cell wont be freed.  So we are safe.  It's a little
fishy, yes.  We could flag the port as closed until its ptab_entry is
set properly.  Closed ports do also have a NULL ptab_entry.

> Why not
> [...] 
>     {
> 	scm_t_port *newport =  scm_add_to_port_table ();
> 	SCM port = scm_cell (scm_tc16_port, newport);
> 	newport->port = port;
> 		      ..
>     }

This will leak newport when the call to scm_cell throws.

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

Re: port initialization?

[Han-Wen Nienhuys]

marius.vollmer@uni-dortmund.de writes:
>>   z = scm_cell (scm_tc16_strport, 0);
>> This looks like fishy code to me. When scm_add_to_port_table triggers
>> GC then it will see the (scm_tc16_strport, 0) cell, which is (or
>> should be) invalid.
>
>Yes, but the GC will not notice since "z" still refers to it and
>therefore the port cell wont be freedo

That's not what I meant: z is a heap cell containing a null
pointer. GC-ing it will dump core.

> > 	SCM port = scm_cell (scm_tc16_port, newport);
> > 	newport->port = port;
> > 		      ..
> >     }
> /
> This will leak newport when the call to scm_cell throws.

scm_cell throws, what do you mean?

-- 
Han-Wen Nienhuys   |   hanwen@cs.uu.nl   |   http://www.cs.uu.nl/~hanwen 

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

Re: port initialization?

[Marius Vollmer]

Han-Wen Nienhuys <hanwen@cs.uu.nl> writes:

> marius.vollmer@uni-dortmund.de writes:
> >>   z = scm_cell (scm_tc16_strport, 0);
> >> This looks like fishy code to me. When scm_add_to_port_table triggers
> >> GC then it will see the (scm_tc16_strport, 0) cell, which is (or
> >> should be) invalid.
> >
> >Yes, but the GC will not notice since "z" still refers to it and
> >therefore the port cell wont be freedo
> 
> That's not what I meant: z is a heap cell containing a null
> pointer. GC-ing it will dump core.

Sure?  Closed ports do contain NULL pointers as well and the GC can
handle them just fine.  The second word of a cell that is tagged as a
port is not a SCM.  The GC knows that and will not try to follow it
(except when freeing a port cell but then only when it is not flagged
as closed).  Am I missing somthing?

> > > 	SCM port = scm_cell (scm_tc16_port, newport);
> > > 	newport->port = port;
> > > 		      ..
> > >     }
> > /
> > This will leak newport when the call to scm_cell throws.
> 
> scm_cell throws, what do you mean?

I meant, when we run out of memory.  Does scm_cell signal an error
then (als scm_misc_error), or does it just abort the process?

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

Re: port initialization?

[Han-Wen Nienhuys]

mvo@zagadka.ping.de writes:
> > >Yes, but the GC will not notice since "z" still refers to it and
> > >therefore the port cell wont be freedo
> > 
> > That's not what I meant: z is a heap cell containing a null
> > pointer. GC-ing it will dump core.
> 
> Sure?  Closed ports do contain NULL pointers as well and the GC can
> handle them just fine.  The second word of a cell that is tagged as a
> port is not a SCM.  The GC knows that and will not try to follow it
> (except when freeing a port cell but then only when it is not flagged
> as closed).  Am I missing somthing?

Perhaps I'm missing something. I think that having null pointers in
the heap is not a good idea, but of course you're right (just
checked), there are lots of checks to prevent a core dump.

> > > > 	SCM port = scm_cell (scm_tc16_port, newport);
> > > > 	newport->port = port;
> > > > 		      ..
> > > >     }
> > > /
> > > This will leak newport when the call to scm_cell throws.
> > 
> > scm_cell throws, what do you mean?
> 
> I meant, when we run out of memory.  Does scm_cell signal an error
> then (als scm_misc_error), or does it just abort the process?

All errors in the GC cause an abort(), AFAIK.

(checking)

No, there are some out-of-memory errors, and scm_misc_errors, mainly
for programming errors (rogue pointer, undefined smob type, etc.). I
think that this is a bad idea. Unwinding the stack (which is done in
scm_error, right?) wlil stop the GC halfway. I think this will lead
unpredictable results.

An out-of-memory error should be handled gracefully, I would says
although I can't really imagine how (there is little code that can
run, if you can't alloc a string or a cell, right?)


-- 
Han-Wen Nienhuys   |   hanwen@cs.uu.nl   |   http://www.cs.uu.nl/~hanwen 

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

Re: port initialization?

[Marius Vollmer]

Han-Wen Nienhuys <hanwen@cs.uu.nl> writes:

> An out-of-memory error should be handled gracefully, I would says
> although I can't really imagine how (there is little code that can
> run, if you can't alloc a string or a cell, right?)

Yep.  I don't think it is worth worrying about his too much.

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

Re: port initialization?

[Han-Wen Nienhuys]

mvo@zagadka.ping.de writes:
> Han-Wen Nienhuys <hanwen@cs.uu.nl> writes:
> 
> > An out-of-memory error should be handled gracefully, I would says
> > although I can't really imagine how (there is little code that can
> > run, if you can't alloc a string or a cell, right?)
> 
> Yep.  I don't think it is worth worrying about his too much.

OK. I made the type-errors in GC abort() guile.

I took a look at the scm_memory_error() calls. From what I gather,
most of them are not really valid, in the sense that they often follow
malloc() calls (as opposed to scm_malloc) -- it might be that GC-ing
frees enough memory to satisfy the request.


-- 

Han-Wen Nienhuys   |   hanwen@cs.uu.nl   |   http://www.cs.uu.nl/~hanwen 

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

Re: port initialization?

[Marius Vollmer]

Han-Wen Nienhuys <hanwen@cs.uu.nl> writes:

> I took a look at the scm_memory_error() calls. From what I gather,
> most of them are not really valid, in the sense that they often follow
> malloc() calls (as opposed to scm_malloc) -- it might be that GC-ing
> frees enough memory to satisfy the request.

I see.  So we should probably replace the calls to malloc with calls
to scm_malloc.  Anyone? :-)


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

Re: port initialization?

[Han-Wen Nienhuys]

mvo@zagadka.ping.de writes:
> > I took a look at the scm_memory_error() calls. From what I gather,
> > most of them are not really valid, in the sense that they often follow
> > malloc() calls (as opposed to scm_malloc) -- it might be that GC-ing
> > frees enough memory to satisfy the request.
> 
> I see.  So we should probably replace the calls to malloc with calls
> to scm_malloc.  Anyone? :-)

in CVS.

--
Han-Wen Nienhuys   |   hanwen@cs.uu.nl   |   http://www.cs.uu.nl/~hanwen 


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

Re: port initialization?

[Marius Vollmer]

Han-Wen Nienhuys <hanwen@cs.uu.nl> writes:

> > I see.  So we should probably replace the calls to malloc with calls
> > to scm_malloc.  Anyone? :-)
> 
> in CVS.

Suuuupercalifragilisticexpi... you get the idea!

-- 
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: port initialization?

[Lynn Winebarger]

On Thursday 08 August 2002 16:14, Marius Vollmer wrote:
> Han-Wen Nienhuys <hanwen@cs.uu.nl> writes:
> 
> > An out-of-memory error should be handled gracefully, I would says
> > although I can't really imagine how (there is little code that can
> > run, if you can't alloc a string or a cell, right?)
> 
> Yep.  I don't think it is worth worrying about his too much.

  If you're running out of memory, you might be in a deeply
recursed procedure that hasn't set any global variables,
so when it aborts, many megabytes become garbage.  It's
not that unusual.

(define (factorial k n)
     (if (= n 0)
          (k 1)
           (factorial (lambda (v) (k (* n v))) (- n 1) )))
(factorial (lambda (v) v) 100000000000000000000000000000000)

     Or is that not included in what you're talking about?

Lynn

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

Re: port initialization?

[Han-Wen Nienhuys]

owinebar@free-expression.org writes:
> > > although I can't really imagine how (there is little code that can
> > > run, if you can't alloc a string or a cell, right?)
> > 
> > Yep.  I don't think it is worth worrying about his too much.
> 
>   If you're running out of memory, you might be in a deeply
> recursed procedure that hasn't set any global variables,
> so when it aborts, many megabytes become garbage.  It's
> not that unusual.

>      Or is that not included in what you're talking about?

It is note that -for instance- on linux you usually can't detect
this condition: malloc always returns non-null but when there is no VM
to satisfy the request, the program is killed.

-- 
Han-Wen Nienhuys   |   hanwen@cs.uu.nl   |   http://www.cs.uu.nl/~hanwen 

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

Re: port initialization?

[Marius Vollmer]

Lynn Winebarger <owinebar@free-expression.org> writes:

>   If you're running out of memory, you might be in a deeply
> recursed procedure that hasn't set any global variables,
> so when it aborts, many megabytes become garbage.  It's
> not that unusual.

Yes, but for throwing the error, we will also need some fresh storage,
I think.  We could arrange things so that aborting will always work,
but I'm afraid that would be quite tricky, and for little gain on a
Unix-like OS.  Might be different for embedded systems.

-- 
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: port initialization?

[Lynn Winebarger]

On Saturday 10 August 2002 08:33, Marius Vollmer wrote:
> Lynn Winebarger <owinebar@free-expression.org> writes:
> 
> >   If you're running out of memory, you might be in a deeply
> > recursed procedure that hasn't set any global variables,
> > so when it aborts, many megabytes become garbage.  It's
> > not that unusual.
> 
> Yes, but for throwing the error, we will also need some fresh storage,
> I think.  We could arrange things so that aborting will always work,
> but I'm afraid that would be quite tricky, and for little gain on a
> Unix-like OS.  Might be different for embedded systems.

    Will it take more than some small fixed amount?  It's not a sin to 
reserve a few words to deal with such situations.
     A related question is, what happens when you're low on memory
and send an interrupt signal?  Will the debugger (be able to) come
up?  Alternatively, to invoke the debugger when it bombs out by keeping
some memory in reserve (make a switch for it).  I suspect guaranteeing that
would require not only a decent call/cc implementation but a way to give the
garbage collector a new chunk of memory to handle (sort of call/cc on the 
gc).  Probably too much work, but it might help writers of such silly algorithms
see the error of their ways.

Lynn


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

Re: port initialization?

[Marius Vollmer]

Lynn Winebarger <owinebar@free-expression.org> writes:

> > Yes, but for throwing the error, we will also need some fresh storage,
> > I think.  We could arrange things so that aborting will always work,
> > but I'm afraid that would be quite tricky, and for little gain on a
> > Unix-like OS.  Might be different for embedded systems.
> 
>     Will it take more than some small fixed amount?

I don't know.  What about handling errors due to lack of memory
specially?  We wouldn't invoke the usual error handler machinery but
just stop and inform the user that we have run out of memory and offer
to retry.  Non-interactive programs might retry periodically.  Just an
idea...

-- 
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: port initialization?

[Han-Wen Nienhuys]

marius.vollmer@uni-dortmund.de writes:
> > Why not
> > [...] 
> >     {
> > 	scm_t_port *newport =  scm_add_to_port_table ();
> > 	SCM port = scm_cell (scm_tc16_port, newport);
> > 	newport->port = port;
> > 		      ..
> >     }
> 
> This will leak newport when the call to scm_cell throws.

We could have a scm_add_to_port_table() that returns an SCM, that
would be less error prone

-- 

Han-Wen Nienhuys   |   hanwen@cs.uu.nl   |   http://www.cs.uu.nl/~hanwen 

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

Re: port initialization?

[Marius Vollmer]

Han-Wen Nienhuys <hanwen@cs.uu.nl> writes:

> We could have a scm_add_to_port_table() that returns an SCM, that
> would be less error prone

That SCM would be the port cell, right?  That would be cleaner, yes.

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

Re: port initialization?

[Han-Wen Nienhuys]

mvo@zagadka.ping.de writes:
> Han-Wen Nienhuys <hanwen@cs.uu.nl> writes:
> 
> > We could have a scm_add_to_port_table() that returns an SCM, that
> > would be less error prone
> 
> That SCM would be the port cell, right?  That would be cleaner, yes.


OK. Changed it.  Should we have a compatibility function? (i.e. is the
old scm_add_to_port_table part of the public C interface of guile?)

-- 

Han-Wen Nienhuys   |   hanwen@cs.uu.nl   |   http://www.cs.uu.nl/~hanwen 

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

Re: port initialization?

[Marius Vollmer]

Han-Wen Nienhuys <hanwen@cs.uu.nl> writes:

> OK. Changed it.  Should we have a compatibility function? (i.e. is the
> old scm_add_to_port_table part of the public C interface of guile?)

Hmm, yes.  It's about on par with the smob functions I'd say, and we
do export those.  The new scm_new_port_table_entry is much easier to
use than the old scm_add_to_port_table, so we should deprecate
scm_add_to_port_table.


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

Re: port initialization?

[Han-Wen Nienhuys]

mvo@zagadka.ping.de writes:
> Hmm, yes.  It's about on par with the smob functions I'd say, and we
> do export those.  The new scm_new_port_table_entry is much easier to
> use than the old scm_add_to_port_table, so we should deprecate
> scm_add_to_port_table.

Done.


--
Han-Wen Nienhuys   |   hanwen@cs.uu.nl   |   http://www.cs.uu.nl/~hanwen 


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