Hi all.
As I was checking out the GC code I realised that I was also printing
statements from the dispose routine of some of my Eiffel classes. Now,
I vaguely recall someone once mentioning that this was a no-no. Is this
something I shouldn't be doing? I removed these print statements and
suddenly the cycle in the rsocfl refused to appear. To the GC experts
here - does this sound reasonable to you? As in, would print statements
within a dispose cause wacky behaviour like this?
Cheers,
Phil.
Phil Malin wrote:
> Hi all.
>
> I think there might be a bug in SmartEiffel's GC (revision 9354).
> Specifically, I've come across a case where the gc_lib.c variable
> 'rsocfl' has a cycle, thus iterating over it causes it to loop forever.
>
> I don't know enough about the gc_lib code to figure out how it
> happened - when I came across this issue I just put in print debug
> statements into gc_lib.c to try and determine where the problem was
> occurring. The actual loop is in 'rsocfl_best_fit' and the second
> while loop, the one in the block starting 'if ((best_size - size) >
> acceptable_loss)'.
>
> The program I wrote that caused this seemes simple enough (although I
> tried to write a smaller one to capture the issue but couldn't
> reproduce it): I had written a class which wraps up a C structure. I
> inherited from DISPOSABLE and had the dispose class 'free' the
> external reference if it hadn't been freed already. The test program
> was just an infinite loop where I created an instance of this class (I
> just wanted to monitor the memory usage to make sure I was mopping up
> correctly).
>
> Has anyone else encountered this? Are there some pointers as to what
> I could try to get more information?
>
> Thanks in advance for any help.
>
> Phil.
>
