Oh, I see! Your answer is what I was looking for. Thanks!
If someone is curious here is this cool piece of code:
1 #include <ruby.h>
2
3 static VALUE str;
4
5 int
6 main(int argc, char **argv)
7 {
8 ruby_init();
9 ruby_init_loadpath();
10
11 str = rb_str_new2("FooBar");
12 /*rb_global_variable(&str);*/ /* Uncomment this if you don't want SF */
13
14 rb_eval_string("GC.start");
15
16 /* Boom! Here comes Segmentation fault */
17 printf("Value: %s\n", StringValuePtr(str));
18
19 ruby_finalize();
20 return 0;
21 }
--
Martins
On 3/31/07, Harold Hausman <hhausman@gmail.com> wrote:
> On 3/31/07, 13 <one.three@gmail.com> wrote:
> > Hi list,
> >
> > On page 284 of Pickaxe, 2nd edition there is a passage:
> >
> > > If you create a Ruby object from C and store it in a C global variable without exporting it to Ruby, you must at least tell the garbage collector about it, lest ye be reaped inadvertently.
> >
>
> Your masochistic behavior scares me a little bit ;), but if I
> understand your intention correctly, you don't *actually* want to call
> rb_define_variable like you do on line 13... I believe calling that
> will cause Ruby to reference the string which is typically a good
> thing, but in this case it's whats causing you to fail to see the
> fireworks that you seek.
>
> Even if Ruby never references your string, and the garbage collector
> does 'reap you inadvertently' you probably wouldn't see the fireworks
> until you happened to dereference the 'str' variable later in your C
> program, and even then only if the memory in question had been filled
> with something interesting in the mean time.
>
> Thats the slippery nature of the descrivbd problem, when you do fall
> victim to it it might be tough to debug, because all you're going to
> have is *occasionally* an 'str' variable filled with something
> strange.
>
> Hope that helps,
> -Harold
>
>