* smobs
@ 2003-05-11 16:44 Dr. Peter Ivanyi
2003-05-12 7:19 ` smobs Thamer Al-Harbash
0 siblings, 1 reply; 8+ messages in thread
From: Dr. Peter Ivanyi @ 2003-05-11 16:44 UTC (permalink / raw)
Hi,
How important to use the scm_must_malloc in the smob creation ?
For example I have a structure with some internal data which is only
accessed by the C part of the code and scheme only sees it through some
functions. If I use malloc it crashes at the first garbage collection
with a simple abort (I think this is during gc, since there is no other
error message), and if I use scm_must_malloc it does not crash. The reason
I am asking this because there can be some other bugs as well and I would
like to be sure that I _have_ to use scm_must_malloc.
Thanks,
Peter Ivanyi
_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: smobs
2003-05-11 16:44 smobs Dr. Peter Ivanyi
@ 2003-05-12 7:19 ` Thamer Al-Harbash
2003-05-12 7:22 ` smobs Thamer Al-Harbash
2003-05-12 12:45 ` smobs Dr. Peter Ivanyi
0 siblings, 2 replies; 8+ messages in thread
From: Thamer Al-Harbash @ 2003-05-12 7:19 UTC (permalink / raw)
On Sun, 11 May 2003, Dr. Peter Ivanyi wrote:
> How important to use the scm_must_malloc in the smob creation ?
All the code seems to do is call malloc and increment a size
counter in the garbage collector. By the looks of it it is meant
for the garbage collector to measure how close it gets to the
threshold which would cause it to run.
On the other hand there's a relationship between
scm_must_malloc() and your smob free routine. If you're not
honest you can get an abort(). Here's the relevant code from
libguile/gc.c:scm_must_malloc():
if (nm < size)
/* The byte count of allocated objects has overflowed. This is
probably because you forgot to report the correct size of freed
memory in some of your smob free methods. */
abort ();
If you're going to use scm_must_malloc() then you have to report
the size in your smob free. Otherwise if you use malloc() it
looks like you should include the size of the data you got with
your own malloc() during your smob free.
Use gdb to see where the abort is being called. If its from that
piece of code, you know why.
--
Thamer Al-Harbash http://www.whitefang.com/
(if (> pressure too-much-pressure)
'flame 'work)
_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: smobs
2003-05-12 7:19 ` smobs Thamer Al-Harbash
@ 2003-05-12 7:22 ` Thamer Al-Harbash
2003-05-12 12:45 ` smobs Dr. Peter Ivanyi
1 sibling, 0 replies; 8+ messages in thread
From: Thamer Al-Harbash @ 2003-05-12 7:22 UTC (permalink / raw)
On Mon, 12 May 2003, Thamer Al-Harbash wrote:
> Otherwise if you use malloc() it looks like you should include
> the size of the data you got with your own malloc() during your
> smob free.
Sorry, that's supposed to read:
Otherwise if you use malloc() it looks like you should not
include the size of the data you got with your own malloc()
during your smob free.
I should start sleeping normal hours :|
--
Thamer Al-Harbash http://www.whitefang.com/
(if (> pressure too-much-pressure)
'flame 'work)
_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: smobs
2003-05-12 7:19 ` smobs Thamer Al-Harbash
2003-05-12 7:22 ` smobs Thamer Al-Harbash
@ 2003-05-12 12:45 ` Dr. Peter Ivanyi
2003-05-12 20:24 ` smobs Thamer Al-Harbash
2003-05-13 17:51 ` smobs Marius Vollmer
1 sibling, 2 replies; 8+ messages in thread
From: Dr. Peter Ivanyi @ 2003-05-12 12:45 UTC (permalink / raw)
Thanks for the answers. I found the bug and it was related to the
reported number of allocations. However now I have a related question.
What should I do if my smob is simply an integer (immediate type)?
Do I have to allocate it or I can simply use it from the local
variable? Basically what confuses me is, that I do not fully understand
what guile will do with an integer if it is passed as a smob.
For example is this correct:
static scm_t_bits data_tag = 0;
static SCM make_my_data(SCM scm_data)
{
int tt;
SCM_ASSERT(SCM_INUM(scm_data), ...);
tt = SCM_INUM(scm_data);
SCM_RETURN_NEWSMOB(data_tag, tt);
}
or I have to allocate the integer and pass that to guile. Moreover
with the above example every time the function is called "tt" will be
created on the stack. Will guile see it properly? Will the stack be
maintained correctly? Does that mean that unless my integer object
is released that stack is growing?
Thanks for your help,
Peter Ivanyi
_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: smobs
2003-05-12 12:45 ` smobs Dr. Peter Ivanyi
@ 2003-05-12 20:24 ` Thamer Al-Harbash
2003-05-13 17:51 ` smobs Marius Vollmer
1 sibling, 0 replies; 8+ messages in thread
From: Thamer Al-Harbash @ 2003-05-12 20:24 UTC (permalink / raw)
On Mon, 12 May 2003, Dr. Peter Ivanyi wrote:
> Thanks for the answers. I found the bug and it was related to the
> reported number of allocations. However now I have a related question.
>
> What should I do if my smob is simply an integer (immediate type)?
> Do I have to allocate it or I can simply use it from the local
> variable? Basically what confuses me is, that I do not fully understand
> what guile will do with an integer if it is passed as a smob.
> For example is this correct:
[snip]
Have you read the "Data Representation" section in the manual? It
goes over this thoroughly. I don't mean to say RTFM, but it does
address your question thoroughly.
--
Thamer Al-Harbash http://www.whitefang.com/
(if (> pressure too-much-pressure)
'flame 'work)
_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: smobs
2003-05-12 12:45 ` smobs Dr. Peter Ivanyi
2003-05-12 20:24 ` smobs Thamer Al-Harbash
@ 2003-05-13 17:51 ` Marius Vollmer
2003-05-14 8:11 ` smobs tomas
1 sibling, 1 reply; 8+ messages in thread
From: Marius Vollmer @ 2003-05-13 17:51 UTC (permalink / raw)
Cc: guile-user@gnu.org
"Dr. Peter Ivanyi" <peteri@carme.sect.mce.hw.ac.uk> writes:
> For example is this correct:
>
> static scm_t_bits data_tag = 0;
>
> static SCM make_my_data(SCM scm_data)
> {
> int tt;
>
> SCM_ASSERT(SCM_INUM(scm_data), ...);
>
> tt = SCM_INUM(scm_data);
>
> SCM_RETURN_NEWSMOB(data_tag, tt);
> }
Yes, you can do that. You need to return 0 in your smob free routine
then.
[ BTW: The memory management for smobs will be much nicer in the 1.8
series of Guile. ]
> Moreover with the above example every time the function is called
> "tt" will be created on the stack. Will guile see it properly?
Since "tt" does not hold a SCM object (it is just an "int"), Guile
does not need to see it.
> Will the stack be maintained correctly? Does that mean that unless
> my integer object is released that stack is growing?
I don't understand. "tt" is a totally ordinary local C variable that
behaves like any other local C variable.
--
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405
_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: smobs
2003-05-13 17:51 ` smobs Marius Vollmer
@ 2003-05-14 8:11 ` tomas
2003-05-14 12:12 ` smobs Dr. Peter Ivanyi
0 siblings, 1 reply; 8+ messages in thread
From: tomas @ 2003-05-14 8:11 UTC (permalink / raw)
Cc: guile-user@gnu.org
On Tue, May 13, 2003 at 07:51:19PM +0200, Marius Vollmer wrote:
> "Dr. Peter Ivanyi" <peteri@carme.sect.mce.hw.ac.uk> writes:
>
> > For example is this correct:
> >
> > static scm_t_bits data_tag = 0;
> >
> > static SCM make_my_data(SCM scm_data)
> > {
> > int tt;
> >
> > SCM_ASSERT(SCM_INUM(scm_data), ...);
> >
> > tt = SCM_INUM(scm_data);
> >
> > SCM_RETURN_NEWSMOB(data_tag, tt);
> > }
>
[...]
> I don't understand. "tt" is a totally ordinary local C variable that
> behaves like any other local C variable.
Ah, I think I get it. Since tt is `just an int', its *content*
gets copied into the smob, not a ref to tt. Thus, no problem if
`tt disappears' as the stack is popped. Does this help, Peter?
Regards
-- tomas
_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: smobs
2003-05-14 8:11 ` smobs tomas
@ 2003-05-14 12:12 ` Dr. Peter Ivanyi
0 siblings, 0 replies; 8+ messages in thread
From: Dr. Peter Ivanyi @ 2003-05-14 12:12 UTC (permalink / raw)
Cc: tomas
tomas@fabula.de wrote:
> Ah, I think I get it. Since tt is `just an int', its *content*
> gets copied into the smob, not a ref to tt. Thus, no problem if
> `tt disappears' as the stack is popped. Does this help, Peter?
Yes, that was it. I have also reread the documentation and it
does indicate it. I was, for some reason, imagening the system
more complicated than it is.
Thanks for everybody's help.
Peter Ivanyi
_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2003-05-14 12:12 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-05-11 16:44 smobs Dr. Peter Ivanyi
2003-05-12 7:19 ` smobs Thamer Al-Harbash
2003-05-12 7:22 ` smobs Thamer Al-Harbash
2003-05-12 12:45 ` smobs Dr. Peter Ivanyi
2003-05-12 20:24 ` smobs Thamer Al-Harbash
2003-05-13 17:51 ` smobs Marius Vollmer
2003-05-14 8:11 ` smobs tomas
2003-05-14 12:12 ` smobs Dr. Peter Ivanyi
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).