dark-panda / ffi-geos

ffi-geos is an implementation of the GEOS Ruby bindings in Ruby via FFI.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

FFI Geos blows up when saving to postgis in rails

sempervictus opened this issue · comments

Issue occurs under MRI and Rubinius, using Rgeo with FFI-geos (RGeo::Geos::FFIFactory). When comitting large numbers of objects to the DB, even MRI dies of a hard stack trace. RBX complains of a pure virtual call when running without threading enabled (rails threadsafe is commented out) as well as a threading issue with the FFI calls when in use.

Top lines of stack traces:

MRI:
/usr/local/rvm/rubies/ruby-1.9.3-p327-fast/lib/libruby.so.1.9(+0x1914c6) [0x7fbb30eb24c6] vm_dump.c:796
/usr/local/rvm/rubies/ruby-1.9.3-p327-fast/lib/libruby.so.1.9(+0x62861) [0x7fbb30d83861] error.c:258
/usr/local/rvm/rubies/ruby-1.9.3-p327-fast/lib/libruby.so.1.9(rb_bug+0xb3) [0x7fbb30d84703] error.c:277
/usr/local/rvm/rubies/ruby-1.9.3-p327-fast/lib/libruby.so.1.9(+0x11ef4f) [0x7fbb30e3ff4f] signal.c:609
/lib/x86_64-linux-gnu/libc.so.6(+0x364a0) [0x7fbb309984a0]
/usr/lib/libgeos_c.so.1(GEOSGetSRID_r+0x26) [0x7fbb24572016] Types.c:63
/usr/local/rvm/gems/ruby-1.9.3-p327-fast@spatial_app/gems/ffi-1.3.1/lib/ffi_c.so(ffi_call_unix64+0x4c) [0x7fbb23fe4430] /usr/local/rvm/gems/ruby-1.9.3-p327-fast@spatial_app/gems/ffi-1.3.1/ext/ffi_c/libffi/src/x86/ffi64.c:633
/usr/local/rvm/gems/ruby-1.9.3-p327-fast@spatial_app/gems/ffi-1.3.1/lib/ffi_c.so(ffi_call+0x423) [0x7fbb23fe3e43] /usr/local/rvm/gems/ruby-1.9.3-p327-fast@spatial_app/gems/ffi-1.3.1/ext/ffi_c/libffi/src/x86/ffi64.c:486
/usr/local/rvm/gems/ruby-1.9.3-p327-fast@spatial_app/gems/ffi-1.3.1/lib/ffi_c.so(rbffi_CallFunction+0x11e) [0x7fbb23fe182e] Call.c:360
/usr/local/rvm/gems/ruby-1.9.3-p327-fast@spatial_app/gems/ffi-1.3.1/lib/ffi_c.so(+0x14176) [0x7fbb23fdd176] MethodHandle.c:224

RBX (running under rails without rails threading enabled):
pure virtual method called
[BUG] Uncaught C++ internal exception
So sorry, it appears that you've encountered an internal
bug. Please report this on the rubinius issue tracker.
Include the following backtrace in the issue:

Abort!
/usr/local/rvm/rubies/rbx-head/bin/rbx(_ZN8rubinius5abortEv+0x29) [0x5ec339]
/usr/local/rvm/rubies/rbx-head/bin/rbx() [0x5e33e5]
/usr/lib/x86_64-linux-gnu/libstdc++.so.6(+0x5ef26) [0x7f3cab647f26]
/usr/lib/x86_64-linux-gnu/libstdc++.so.6(+0x5ef53) [0x7f3cab647f53]
/usr/lib/x86_64-linux-gnu/libstdc++.so.6(+0x5fa6f) [0x7f3cab648a6f]
/usr/lib/libgeos_c.so.1(GEOSisEmpty_r+0x29) [0x7f3c8ba5cb49]
/usr/local/rvm/rubies/rbx-head/bin/rbx(ffi_call_unix64+0x4c) [0x7ca500]
/usr/local/rvm/rubies/rbx-head/bin/rbx(ffi_call+0x40c) [0x7c9f0b]
/usr/local/rvm/gems/rbx-head@spatial_app/gems/ffi-1.3.1/lib/ffi_c.so(rbffi_CallFunction+0x127) [0x7f3c8b4d11c7]
/usr/local/rvm/rubies/rbx-head/bin/rbx() [0x6f6835]

RBX (running under rails in production with threading enabled):
/usr/local/rvm/rubies/rbx-head/bin/rbx[0x5e30fe]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0)[0x7f8c5de27cb0]
/usr/lib/x86_64-linux-gnu/libstdc++.so.6(__dynamic_cast+0x38)[0x7f8c5e6d7988]
/usr/lib/libgeos_c.so.1(GEOSGeomGetNumPoints_r+0x32)[0x7f8c3ec27a12]
/usr/local/rvm/rubies/rbx-head/bin/rbx(ffi_call_unix64+0x4c)[0x7ca500]
/usr/local/rvm/rubies/rbx-head/bin/rbx(ffi_call+0x40c)[0x7c9f0b]
/usr/local/rvm/gems/rbx-head@spatial_app/gems/ffi-1.3.1/lib/ffi_c.so(rbffi_CallFunction+0x127)[0x7f8c3e69a1c7]
/usr/local/rvm/rubies/rbx-head/bin/rbx[0x6f6835]

This happens with libgeos 3.3.3-3.3.6, gems reinstalled at every lib rebuild, ffi-geos passes all tests. Suggestions?

Suspicion falls on https://github.com/dark-panda/ffi-geos/blob/master/lib/ffi-geos.rb#L1034 which makes use of a Thread local, as does L1006. Is there any way that those can be converted to instance variables so we can keep them encapsulated in the object? if run in the context of something like Celluloid which can affect Thread locals, problems can occur.

The plot thickens. I've removed the Thread locals (see #18 ), and both MRI and RBX are still producing a segfault, though no longer threading related at all. Now we're down to what appears to be the same issue on both platforms, and appearing consistently in threaded production and single threaded dev mode.

MRI now throws (without a subsequent stack trace):

pure virtual method called
terminate called without an active exception
Aborted

while RBX simply says:

Segmentation fault

Finalizers? Something else?

commented

Could you please provide a test script that I can try out in my environment, preferably a standalone script without any dependencies on RGeo if possible? Cheers.

I've been trying to reproduce outside the rails app and so far, no luck. I've even created a new rails app with the RGeo components in it and a simple model to absorb the data, and still no dice - runs just fine, complains about encoding issues on commit in some cases, but no crash like the full application.

commented

Closing due to inactivity. Please re-open if you find a minimal test script that reproduces the problem, though!