Robert Klemme
3/24/2009 7:27:00 PM
On 24.03.2009 20:07, Peter Zotov wrote:
> Quoting "Robert Klemme" <shortcutter@googlemail.com>:
>
>> On 24.03.2009 19:09, Peter Zotov wrote:
>>> Quoting "Robert Klemme" <shortcutter@googlemail.com>:
>>>> 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