Dear Mr. Matz,

Thanks for your response.  Actually, after tracing and printing all
the variable addresses, I concluded that my mark functions are fine. 
Finally I found out that the segmentation fault happenned because I
have some C global variables in my extension that are of type VALUE
and free floating.  Apparently they got swept by the garbage
collector.  After I put them under "rb_define_readonly_variable", my
program works without any problem as expected.

However, using "rb_define_readonly_variable" still exposes my C global
variables to the user, although they are read only.  Is there any way
to hide them completely from the user?  I.e., is there any other easy
way to mark the global variables?

Regards,

Bill
=============================================================================
matz / ruby-lang.org (Yukihiro Matsumoto) wrote in message news:<1028075584.326581.7071.nullmailer / picachu.netlab.jp>...
> Hi,
> 
> In message "Re: Segmentation Fault - Ruby Garbage Collection"
>     on 02/07/31, Bill Tj <billtj / glue.umd.edu> writes:
> 
> |Now, clearly the symptom is like this.  If I disable garbage collecter
> |by invoking "GC.disable", my program runs without any problem. 
> |Otherwise, I get segmentation fault.  Does this give a clue that the
> |problem is very likely to be in my mark functions?  Are there any more
> |rules on how to invoke rb_gc_mark in the mark functions beside just
> |calling rb_gc_mark for every Ruby objects inside a structure?  The
> |function prototype in Ruby 1.6.7 is rb_gc_mark (void) (what is the
> |correct prototype?  And should I recompile my Ruby installation?); can
> |this be a source of problem?
> 
> Show me the code, at least your mark function.
> 
> 							matz.