On Fri, Dec 10, 2010 at 12:25 AM, Wayne Meissner <wmeissner@gmail.com> wrote:

> On 10 December 2010 12:21, dark.panda <dark.panda@gmail.com> wrote:
>

>> Anyone have any ideas as to what's going on? I'm at my wits end at
>> this point. Modifying GEOS itself might not be an option, but if
>> there's something I can do in Ruby that would be awesome.

>
> I haven't looked in depth, but in that cut down gist, it _could_ be this:
>
> handle = FFIGeos.initGEOS_r(
>  self.method(:notice_handler),
>  self.method(:error_handler)
> )
>
> Stash the return values from self.method() somewhere.
> e.g.
>
> @nh = self.method(:notice_handler)
> @eh = self.method(:error_handler)
> handle = FFIGeos.initGEOS_r(@nh, @eh))
>
> They don't have to be ivars, but they need to be kept for as long as
> Geos needs to use the callbacks.
>

Ah, I think this may well be it! The minimal test runs and, even
better, so does the entire unit test suite! Cheers!

I wrote up a quick patch to store the values from the error handler
methods in Thread.current and everything seems to be working as
expected including multithreading which is tremendous.

I take it that garbage collection was trying to clean up some things
it shouldn't and that was wreaking havoc, yeah? I'd like to step
through this in gdb when I get a chance now that I know what to look
for to try and understand what's happening in more detail, but for now
I'm ecstatic that things appear to be working. This was the last major
(known) issue in the library and I think a beta release is due for
some testing.

Cheers again, and thanks!

J