Hi Paul,

I was puzzled by the example itself; hopefully it is really just an
example:

1) Why do you have a vector of char* instead of std::vector<string> in
C++?  In this case you don't get the advantage of the string copy
constructor when you call the push_back() on the vector, which then
requires you to store the corresponding VALUE.

2) Why do you want store the char* of the VALUE instead of the VALUE
itself?  You can then store the VALUE in a global ruby array instead of a
global vector so that you don't need rb_global_variable(&argv[0]).

3) By its name, rb_global_variable() is supposed to store a C global
variable (of type VALUE); so when we call rb_global_variable() for a
temporary C variable, at that point the C code design is questionable.

Therefore, based on 1), 2), and 3) I don't see any problem that
rb_global_variable() (or rb_gc_register_address()) stores VALUE* instead
of VALUE.

Finally, if there is a technique that can track this kind of bug down
easily, please let us all know, since it will make C programming in
Ruby much safer (and much more fun :) ).

Regards,

Bill
====================================================================
Paul Brannan <pbrannan / atdesk.com> wrote:
> We ran into a problem today with the garbage collector (caused by our
> own bug).  We had a function that did something like this:
>   std::vector<char *> foo;
>   void func(int argc, VALUE * argv, VALUE self) {
>     foo.push_back(STR2CSTR(argv[0]));
>     rb_global_variable(&argv[0]);
>   }

> This is a bug, because once the function returns, argv[0] is invalid,
> and global_List contains an invalid VALUE* that may or may not point to
> the VALUE we want to keep global.  When the GC tries to mark this
> VALUE*, it ends up marking an invalid object.

> So my question is: why does rb_gc_register_address() store VALUE*'s
> instead of VALUE's?  I suppose that if it stored a VALUE, then it would
> be possible to register an object as a global but not keep a reference
> to that object; this may not be desirable.  In our case, though, we just
> wanted the string to remain valid.

> If I do have a bug like this in the future, what techniques can I use to
> track it down?

> Paul