Re: Manual Memory Management and Automatic Garbage Collection

On 12/06/2010 08:19 PM, Tridib Bandopadhyay wrote:
> Jeremy Bopp wrote in post #966541:
> 
>> Have you tried sprinkling some printf statements throughout gc.c
>> yourself yet?  If the diagnostic instrumentation for gc.c is hard to
>> find or does not exist, adding your own can at least help you make some
>> progress.
>>
>> To start, you could add a printf with the function name at the beginning
>> of each function in gc.c.  Then run your build of ruby with your test
>> scripts to trigger garbage collection and see what gets printed.  That
>> should give you a lead on where to add more printf calls to gc.c in
>> order to gather more detailed information.
>>
>> -Jeremy
> 
> 
> Yes I have tried that long back.. for example in this code fragment--
> 
> VALUE
> rb_newobj()
> {
>     VALUE obj;
>     printf("newobj");     /*My own line*/
>     if (!freelist) garbage_collect();
> 
>     obj = (VALUE)freelist;
>     freelist = freelist->as.free.next;
>     MEMZERO((void*)obj, RVALUE, 1);
> #ifdef GC_DEBUG
>     RANY(obj)->file = ruby_sourcefile;
>     RANY(obj)->line = ruby_sourceline;
> #endif
>     return obj;
> }
> 
> But when I am making this change and trying to compile my ruby. It is 
> bombing out with a message Segmentation failure and it is printing my 
> print statement numerous times before bombing out.I also tried in my 
> other functions.

Ruby creates plenty of objects during its normal operation, so this
function will be called frequently.  It makes sense then that you'll see
your output many times.  What doesn't make sense is the segmentation fault.

I would bet that you had more changes than just that single line in gc.c
when you built your modified version of Ruby.  If that's the case, it's
likely that one of your other changes is the culprit.  I suggest that
you try again from a completely fresh set of sources and add only that
single line to see if you can avoid the problem.

> Also can you tell me when we compile the ruby with 'make' command how 
> does it changes the gc.c file in the executable file.

I'm not sure I understand what you're asking unless you're really asking
for the details of how the compiler works.  Generally, the compiler is
used to compile each source file into a corresponding object (*.o) file.
 Once all object files are created, they are then linked into the ruby
executable.  In this case, gc.c would be compiled into gc.o which would
ultimately be linked into ruby.

The make program is usually smart enough to only rebuild the .o files
whose corresponding .c files were updated since the last build run, so
if you only change gc.c, only gc.c should be recompiled.  Then the ruby
program should be recreated by linking the new gc.o file in along with
all the other .o files.

None of that really matters for you though.  All you need to do is make
your changes to gc.c and then run make.  You should see some output
during the make process that indicates that gc.c is being compiled and
that ultimately a new ruby file is created.  Try not to get sidetracked
on the details.

-Jeremy