Windows Seg Fault
cfis opened this issue · comments
So ffi-geos have never really worked on windows, geometries end up as null. But I just upgraded to latest gcc and now this gem segaults. Note that other ffi based gems seem to work correctly, so I don't think its ffi.
Nor do I think this is an issue with geos. Postgresql 9.5.1 and latest postgis and geos work fine. I can run queries like this:
select bounds, st_asewkt(bounds), st_asewkt(ST_ClipByBox2D(bounds, ST_MakeEnvelope(0,0,10,10)))
from items_cache
where bounds IS NOT NULL
That leads me to think that somehow its in ffi-geos.
gcc version 5.3.0 (Rev4, Built by MSYS2 project)
This is the trace:
C:/msys64/local/src/ffi-geos/lib/ffi-geos/wkb_reader.rb:34: [BUG] Segmentation fault
ruby 2.3.0p0 (2015-12-25 revision 53290) [x64-mingw32]
-- Control frame information -----------------------------------------------
c:0027 p:---- s:0130 e:000129 CFUNC :GEOSWKBReader_readHEX_r
c:0026 p:0042 s:0123 e:000121 METHOD C:/msys64/local/src/ffi-geos/lib/ffi-geos/wkb_reader.rb:34
c:0025 p:0022 s:0116 e:000115 METHOD C:/msys64/local/src/ffi-geos/test/wkb_reader_tests.rb:17
c:0024 p:0034 s:0105 e:000104 METHOD C:/msys64/local/src/ffi-geos/test/wkb_reader_tests.rb:52
Hm, I think I used to have the whole test suite running on MinGW. It's been a long time since I tested in that environment, but I still have the VM images I used. Let me dig up my MinGW VM and I'll take a look.
Just to be clear, mingw64, not mingw.
I am ussing msys2, and then use its package manager to install the latest gcc. I'll see if I can setup a debugger also and figure out what's going on.
Ok, spent a fair bit of time on this, but came up with an unsatisfying answer. If build geos not specifying any flags it uses the -O2 optimization level. To create an easier to debug build, I set it to -O0 and the problem went away.
With -O2 level, the segfault comes from geos_ts_c.cpp, line 4852:
std::istringstream is(std::ios_base::binary)
That then ends up here:
Program received signal SIGSEGV, Segmentation fault.
0x0000000004dc26cc in basic_istream (__vtt_parm=, this=0x72d170, __in_chrg=) at C:/msys64/mingw64/include/c++/5.3.0/istream:607
607 : _M_gcount(streamsize(0))
Why that lines crashes...no idea...seems pretty innocuous.
By "the problem went away", do you mean the tests succeeded or at least the segfault disappeared?
What is PostGIS and GEOS using for your Postgres set up? Is it also using -O2?
I don't have a mingw64 environment set up at the moment but I could get one running I think. Any chance on getting a backtrace leading up to the segfault?
Yes, segfault went away and tests pass. PostGiS and Postgres were compiled based on whatever the default settings are when you do ./configure on them. I assume its -O2 but didn't check.
Backtrace, yes. I assume there really is some sort of issue here, but I couldn't see what it was. The parameters to the reader looked fine. The handler pointer, the reader pointer, and of course the hex string. I was using the first test in the reader files, which passes 42 byte long string. The string data in memory looked correct, the length looked correct, and the 43rd byte was a null character as expected.
I see no reason for the istream to fail getting created on the stack...but it does when compiled with -O2
Yeah, that's definitely weird. I don't know what it could be other than perhaps over-optimization by gcc something to that effect producing bad code.
I'll try to reproduce this how about. Is there an easy way to get an image up and running for this these days? The last time I set this up I used a modern.ie image and installed MinGW on that, so I could do the same with MinGW64 and try to mimic your environment. I'm assuming GEOS 3.5.0 by the looks of it?
Closing due to inactivity.