From: Robert Klemme Date: 2009-03-25T04:26:55+09:00 Subject: Re: Strange bug in irb1.9 On 24.03.2009 20:07, Peter Zotov wrote: > Quoting "Robert Klemme" : > >> On 24.03.2009 19:09, Peter Zotov wrote: >>> Quoting "Robert Klemme" : >>>> Spontaneously two things come to mind: garbage collection (because >>>> of the seemingless random timing) and real threads (which are >>>> introduced in 1.9). Maybe your cleanup code is not thread safe or >>>> does not play well with concurrent GC (not sure whether the 1.9 >>>> runtime really does this but it uses native threads IIRC). >>> Disabling GC solved this problem. I think only this >>> Data_Wrap_Struct(rb_cObject, 0, 0, setting) >>> place of code can be buggy. >>> I passed NULL to "free" parameter because I do not allocate memory for >>> setting structure and do not free it (not sure what will be if it is >>> freed by library, probably I need to make some checks). What do I need >>> to pass as destructor in this case? >> I have to create a C extension yet, but you certainly need to >> clearly separate memory that you allocate in the extension and >> memory that you allocate via Ruby's core. The first type needs to >> be manually freed in the extension and the latter is probably >> subject to GC. But someone else will be able to answer this much >> better than I can. You could as well look into another extension >> and see how they do it there. > > The problem is that I do not allocate that memory in _extension_. It > is allocated by wrapped library, not me. Okay, I added hooks that > notify Ruby objects that setting was freed by library, and changed 0 > in "free" parameter of Data_Wrap_Struct to empty destructor. > Nothing happened, same segfault is in same place. I consider the lib as part of the extension for this example. The difference is really which malloc is used. Cheers robert -- remember.guy do |as, often| as.you_can - without end