* Problem with smobs
@ 2006-05-30 9:22 Joris van der Hoeven
2006-05-30 9:53 ` Mikael Djurfeldt
2006-05-30 9:55 ` R. Mattes
0 siblings, 2 replies; 9+ messages in thread
From: Joris van der Hoeven @ 2006-05-30 9:22 UTC (permalink / raw)
Hi all,
I noticed a strange problem with the memory allocation of smobs and
I fail to understand whether I am doing something wrong or whether
this is a bug in Guile.
Consider the (C++) smob code attached below to this message.
All memory allocations are done from within C++, so the free_mysmob
function returns 0. Now consider the following session:
Guile> (define x (mysmob 2))
make smob
Guile> (gc)
mark smob
Guile> (set! x #f)
Guile> (gc)
free smob
So far so good. But now
Guile> (define x (mysmob 2))
make smob
Guile> (begin (display x) (display "\n"))
print smob
#<mysmob 2>
Guile> (set! x #f)
Guile> (gc)
mark smob
In other words: printing the smob prevents the memory from being released.
Does "display" admit some hidden (and undocumented) side effects?
Did I do something wrong? Is this a bug in Guile?
Any help would be appreciated.
Best wishes, Joris
-----------------------------------------------------------------------------
static scm_bits_t mysmob_tag;
struct mysmob {
int val;
inline mysmob (int val2): val (val2) {}
};
static SCM
make_mysmob (SCM s_val) {
cout << "make smob\n";
SCM_ASSERT (SCM_INUMP (s_val), s_val, SCM_ARG1, "make-image");
int val= SCM_INUM (s_val);
mysmob *obj= new mysmob (val);
SCM_RETURN_NEWSMOB (mysmob_tag, obj);
}
static SCM
increment_mysmob (SCM smob) {
cout << "increment smob\n";
SCM_ASSERT (SCM_SMOB_PREDICATE (mysmob_tag, smob),
smob, SCM_ARG1, "increment-mysmob");
mysmob* obj= (mysmob*) SCM_SMOB_DATA (smob);
mysmob* ret= new mysmob (obj->val + 1);
SCM_RETURN_NEWSMOB (mysmob_tag, ret);
}
static SCM
mark_mysmob (SCM smob) {
cout << "mark smob\n";
(void) smob;
return SCM_BOOL_F;
}
static size_t
free_mysmob (SCM smob) {
cout << "free smob\n";
mysmob* obj = (mysmob*) SCM_SMOB_DATA (smob);
delete obj;
return 0;
}
static int
print_mysmob (SCM smob, SCM port, scm_print_state *pstate) {
cout << "print smob\n";
mysmob *obj = (mysmob*) SCM_SMOB_DATA (smob);
scm_puts ("#<mysmob ", port);
scm_display (int_to_scm (obj->val), port);
scm_puts (">", port);
/* non-zero means success */
return 1;
}
typedef SCM (*scheme_primitive) ();
void
init_mysmob_type () {
mysmob_tag = scm_make_smob_type ("mysmob", sizeof (struct mysmob));
scm_set_smob_mark (mysmob_tag, mark_mysmob);
scm_set_smob_free (mysmob_tag, free_mysmob);
scm_set_smob_print (mysmob_tag, print_mysmob);
scm_c_define_gsubr ("mysmob", 1, 0, 0,
(scheme_primitive) (void*) make_mysmob);
scm_c_define_gsubr ("mysmob-inc", 1, 0, 0,
(scheme_primitive) (void*) increment_mysmob);
}
_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Problem with smobs
2006-05-30 9:22 Problem with smobs Joris van der Hoeven
@ 2006-05-30 9:53 ` Mikael Djurfeldt
2006-05-30 10:09 ` Joris van der Hoeven
2006-05-30 13:55 ` Ludovic Courtès
2006-05-30 9:55 ` R. Mattes
1 sibling, 2 replies; 9+ messages in thread
From: Mikael Djurfeldt @ 2006-05-30 9:53 UTC (permalink / raw)
Cc: guile-user
On 5/30/06, Joris van der Hoeven <vdhoeven@texmacs.org> wrote:
> Hi all,
>
> I noticed a strange problem with the memory allocation of smobs and
> I fail to understand whether I am doing something wrong or whether
> this is a bug in Guile.
>
> Consider the (C++) smob code attached below to this message.
> All memory allocations are done from within C++, so the free_mysmob
> function returns 0. Now consider the following session:
>
> Guile> (define x (mysmob 2))
> make smob
> Guile> (gc)
> mark smob
> Guile> (set! x #f)
> Guile> (gc)
> free smob
>
> So far so good. But now
>
> Guile> (define x (mysmob 2))
> make smob
> Guile> (begin (display x) (display "\n"))
> print smob
> #<mysmob 2>
> Guile> (set! x #f)
> Guile> (gc)
> mark smob
>
> In other words: printing the smob prevents the memory from being released.
> Does "display" admit some hidden (and undocumented) side effects?
> Did I do something wrong? Is this a bug in Guile?
> Any help would be appreciated.
I wouldn't call this a bug and wouldn't call it undocumented. The
garbage collector only guarantees that it doesn't free things which
you can reference. It doesn't guarantee whether to or when to free
things which lack a reference.
In this case my guess is that some reference to your smob remains on
the stack or in some data structure associated with printing (like the
print-state) immediately after printing. That reference will very
likely pretty soon disappear after some further execution.
_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Problem with smobs
2006-05-30 9:22 Problem with smobs Joris van der Hoeven
2006-05-30 9:53 ` Mikael Djurfeldt
@ 2006-05-30 9:55 ` R. Mattes
2006-05-30 10:12 ` Joris van der Hoeven
1 sibling, 1 reply; 9+ messages in thread
From: R. Mattes @ 2006-05-30 9:55 UTC (permalink / raw)
Cc: guile-user
On Tue, 2006-05-30 at 11:22 +0200, Joris van der Hoeven wrote:
> Hi all,
>
> I noticed a strange problem with the memory allocation of smobs and
> I fail to understand whether I am doing something wrong or whether
> this is a bug in Guile.
>
> Consider the (C++) smob code attached below to this message.
> All memory allocations are done from within C++, so the free_mysmob
> function returns 0. Now consider the following session:
Since you seem to test from the REPL: do you have value history enabled
by accident (something like "(use-modules (ice-9 history))" in your
guile init file)? Anything printed will be kept bound to $1, $2 ... $n.
HTH Ralf Mattes
>
>
> _______________________________________________
> Guile-user mailing list
> Guile-user@gnu.org
> http://lists.gnu.org/mailman/listinfo/guile-user
_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Problem with smobs
2006-05-30 9:53 ` Mikael Djurfeldt
@ 2006-05-30 10:09 ` Joris van der Hoeven
2006-05-30 10:27 ` Mikael Djurfeldt
2006-05-30 13:55 ` Ludovic Courtès
1 sibling, 1 reply; 9+ messages in thread
From: Joris van der Hoeven @ 2006-05-30 10:09 UTC (permalink / raw)
Cc: guile-user
On Tue, May 30, 2006 at 11:53:34AM +0200, Mikael Djurfeldt wrote:
> >In other words: printing the smob prevents the memory from being released.
> >Does "display" admit some hidden (and undocumented) side effects?
> >Did I do something wrong? Is this a bug in Guile?
> >Any help would be appreciated.
>
> I wouldn't call this a bug and wouldn't call it undocumented. The
> garbage collector only guarantees that it doesn't free things which
> you can reference. It doesn't guarantee whether to or when to free
> things which lack a reference.
>
> In this case my guess is that some reference to your smob remains on
> the stack or in some data structure associated with printing (like the
> print-state) immediately after printing. That reference will very
> likely pretty soon disappear after some further execution.
Hmm, printing "\n" does not seem to suffice. But after recursively
printing a large object, the memory gets freed. It might be good to add
a note about this in the smob documentation, because one of the first
tests one usually does after writing a smob type is to print some smobs.
If objects don't get freed, even after a gc, then this is somewhat confusing.
So I still would call this an undocument side-effect of "display".
How much precisely is kept on the stack or in print-states?
Thanks for your quick reply, Joris
_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Problem with smobs
2006-05-30 9:55 ` R. Mattes
@ 2006-05-30 10:12 ` Joris van der Hoeven
0 siblings, 0 replies; 9+ messages in thread
From: Joris van der Hoeven @ 2006-05-30 10:12 UTC (permalink / raw)
Cc: guile-user
On Tue, May 30, 2006 at 11:55:56AM +0200, R. Mattes wrote:
> On Tue, 2006-05-30 at 11:22 +0200, Joris van der Hoeven wrote:
> > Hi all,
> >
> > I noticed a strange problem with the memory allocation of smobs and
> > I fail to understand whether I am doing something wrong or whether
> > this is a bug in Guile.
> >
> > Consider the (C++) smob code attached below to this message.
> > All memory allocations are done from within C++, so the free_mysmob
> > function returns 0. Now consider the following session:
>
> Since you seem to test from the REPL: do you have value history enabled
> by accident (something like "(use-modules (ice-9 history))" in your
> guile init file)? Anything printed will be kept bound to $1, $2 ... $n.
No, the example comes from an interactive TeXmacs session without history.
The problem seems to be due to a side-effect of display concerning
the print state. It might be good to document this side-effect.
Thanks, Joris
_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Problem with smobs
2006-05-30 10:09 ` Joris van der Hoeven
@ 2006-05-30 10:27 ` Mikael Djurfeldt
2006-05-30 18:26 ` Neil Jerram
0 siblings, 1 reply; 9+ messages in thread
From: Mikael Djurfeldt @ 2006-05-30 10:27 UTC (permalink / raw)
Cc: guile-user
On 5/30/06, Joris van der Hoeven <vdhoeven@texmacs.org> wrote:
> > In this case my guess is that some reference to your smob remains on
> > the stack or in some data structure associated with printing (like the
> > print-state) immediately after printing. That reference will very
> > likely pretty soon disappear after some further execution.
>
> [...]
> So I still would call this an undocument side-effect of "display".
> How much precisely is kept on the stack or in print-states?
I don't remember. You'll have to look it up in the source code or wait
for a reply from someone else.
_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Problem with smobs
2006-05-30 9:53 ` Mikael Djurfeldt
2006-05-30 10:09 ` Joris van der Hoeven
@ 2006-05-30 13:55 ` Ludovic Courtès
1 sibling, 0 replies; 9+ messages in thread
From: Ludovic Courtès @ 2006-05-30 13:55 UTC (permalink / raw)
Cc: guile-user, Joris van der Hoeven
Hi,
"Mikael Djurfeldt" <mdjurfeldt@gmail.com> writes:
> I wouldn't call this a bug and wouldn't call it undocumented. The
> garbage collector only guarantees that it doesn't free things which
> you can reference. It doesn't guarantee whether to or when to free
> things which lack a reference.
Well, I agree, but still, the fact that a reference is unwillingly held
for an undefined amount of time qualifies as a leak IMO. ;-)
This particular leak should be fixed in 1.8:
http://lists.gnu.org/archive/html/guile-devel/2005-11/msg00016.html .
Thanks,
Ludovic.
_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Problem with smobs
2006-05-30 10:27 ` Mikael Djurfeldt
@ 2006-05-30 18:26 ` Neil Jerram
2006-05-30 19:20 ` Joris van der Hoeven
0 siblings, 1 reply; 9+ messages in thread
From: Neil Jerram @ 2006-05-30 18:26 UTC (permalink / raw)
Cc: djurfeldt, guile-user
"Mikael Djurfeldt" <mdjurfeldt@gmail.com> writes:
> On 5/30/06, Joris van der Hoeven <vdhoeven@texmacs.org> wrote:
>> > In this case my guess is that some reference to your smob remains on
>> > the stack or in some data structure associated with printing (like the
>> > print-state) immediately after printing. That reference will very
>> > likely pretty soon disappear after some further execution.
>>
>> [...]
>> So I still would call this an undocument side-effect of "display".
>> How much precisely is kept on the stack or in print-states?
>
> I don't remember. You'll have to look it up in the source code or wait
> for a reply from someone else.
In any case this bug is fixed now in 1.8 CVS, and in the 1.6.8
release. Does that help you?
Neil
_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Problem with smobs
2006-05-30 18:26 ` Neil Jerram
@ 2006-05-30 19:20 ` Joris van der Hoeven
0 siblings, 0 replies; 9+ messages in thread
From: Joris van der Hoeven @ 2006-05-30 19:20 UTC (permalink / raw)
Cc: djurfeldt, guile-user
On Tue, May 30, 2006 at 07:26:22PM +0100, Neil Jerram wrote:
> "Mikael Djurfeldt" <mdjurfeldt@gmail.com> writes:
>
> > On 5/30/06, Joris van der Hoeven <vdhoeven@texmacs.org> wrote:
> >> > In this case my guess is that some reference to your smob remains on
> >> > the stack or in some data structure associated with printing (like the
> >> > print-state) immediately after printing. That reference will very
> >> > likely pretty soon disappear after some further execution.
> >>
> >> [...]
> >> So I still would call this an undocument side-effect of "display".
> >> How much precisely is kept on the stack or in print-states?
> >
> > I don't remember. You'll have to look it up in the source code or wait
> > for a reply from someone else.
>
> In any case this bug is fixed now in 1.8 CVS, and in the 1.6.8
> release. Does that help you?
Sure; thank you all for the fast feedback. --Joris
_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2006-05-30 19:20 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-05-30 9:22 Problem with smobs Joris van der Hoeven
2006-05-30 9:53 ` Mikael Djurfeldt
2006-05-30 10:09 ` Joris van der Hoeven
2006-05-30 10:27 ` Mikael Djurfeldt
2006-05-30 18:26 ` Neil Jerram
2006-05-30 19:20 ` Joris van der Hoeven
2006-05-30 13:55 ` Ludovic Courtès
2006-05-30 9:55 ` R. Mattes
2006-05-30 10:12 ` Joris van der Hoeven
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).