#656 test-suite/newobject[12].i fail with Ruby (not GC'ed??)

closed
cfis
ruby (61)
5
2007-04-29
2006-03-26
rickhg12hs
No

Both test-suite cases newobject1 and newobject2 fail on:

redhat-amd64/ruby-1.8.4/swig-1.3.28
cygwin/ruby-1.8.4/swig-1.3.25

It seems that the RuntimeErrors occur because
Foo.fooCount is not decremented after setting an
allocated variable to nil and calling the garbage
collector.

I'm not sure if this is a Ruby issue or a SWIG issue.

I have not checked if swig-1.3.29 fixes this ... sorry.

Discussion

  • rickhg12hs

    rickhg12hs - 2006-04-01

    Logged In: YES
    user_id=931787

    Both test-suite cases newobject1 and newobject2 also fail
    identically on:

    redhat-amd64/ruby-1.8.4/swig-1.3.29

     
  • Marcelo Matus

    Marcelo Matus - 2006-04-02

    Logged In: YES
    user_id=246059

    how do they fail?

    what ruby and gcc version are you using?

    here they seem to run fine.

    Marcelo

     
  • rickhg12hs

    rickhg12hs - 2006-04-04

    Logged In: YES
    user_id=931787

    redhat-amd64/ruby-1.8.4/swig-1.3.29

    gcc version 3.4.3

    It fails during the newobject[12]_runme.rb tests as
    described above.

     
  • rickhg12hs

    rickhg12hs - 2006-05-04

    Logged In: YES
    user_id=931787

    After being unable to find a platform where these tests pass
    (what is your platform where it does work?), and learning a
    bit more about Ruby's conservative GC, I'm wondering if
    these tests can reliably pass.

     
  • William Fulton

    William Fulton - 2006-09-25

    Logged In: YES
    user_id=242951

    They fail for me on suse 10.1, gcc-4.1 ruby 1.8.4. Fails
    with older versions of swig too (eg 1.3.25). Everything okay
    with my older platforms eg gcc <= 3.4 (cygwin, solaris,
    linux). So definitely a problem here, exposed by newer gcc /
    Ruby.

     
  • Gonzalo Garramuno

    Logged In: YES
    user_id=961712
    Originator: NO

    It is not a SWIG issue, but a Ruby GC one. Ruby is internally keeping a reference to the object in the stack and marking it for longer than should be needed.

    Personally, I consider this a ruby bug in its GC, but there may be a good reason for this to happen and be necessary.

    The newobject* tests have been changed to reflect this issue and you can see that no memory is leaked (only one or two additional objects are still kept in memory by ruby's stack instead of the 100s created).

     
  • Gonzalo Garramuno

    • status: open --> closed
     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks