GeometryComponentFilter::filter_ro: Assertion `0' failed

[aaronharris]

i have just installed from source version 3.3.3 on centos64. I am getting the following error when running make check. Is there a dependency that I missed?

make[3]: Entering directory `/usr/local/src/geos-3.3.3/geos-3.3.3/tests/xmltester' lt-XMLTester: GeometryComponentFilter.cpp:35: virtual void geos::geom::GeometryComponentFilter::filter_ro(const geos::geom::Geometry*): Assertion `0' failed. ./testrunner: line 2: 19874 Aborted (core dumped) ./XMLTester -v --test-valid-output ./tests/testLeaksBig.xml ./tests/split.xml ./tests/hexwkb.xml ./tests/test.xml ./tests/linemerge.xml ./tests/TestIsValid.xml ./tests/robustness.xml ./tests/buffer.xml ./tests/singlesidedbuffer.xml ./tests/ticket/bug176.xml ./tests/ticket/bug188.xml ./tests/ticket/bug244.xml ./tests/ticket/bug275.xml ./tests/ticket/bug350.xml ./tests/ticket/bug356.xml ./tests/ticket/bug358.xml ./tests/ticket/bug360.xml ./tests/ticket/bug366.xml ./tests/ticket/bug392.xml ./tests/ticket/bug398.xml ./tests/ticket/bug434.xml ./tests/ticket/bug488.xml ./tests/general/TestBoundary.xml ./tests/general/TestBuffer.xml ./tests/general/TestBufferMitredJoin.xml ./tests/general/TestCentroid.xml ./tests/general/TestConvexHull.xml ./tests/general/TestConvexHull-big.xml ./tests/general/TestDistance.xml ./tests/general/TestFunctionAAPrec.xml ./tests/general/TestFunctionAA.xml ./tests/general/TestFunctionLAPrec.xml ./tests/general/TestFunctionLA.xml ./tests/general/TestFunctionLLPrec.xml ./tests/general/TestFunctionLL.xml ./tests/general/TestFunctionPA.xml ./tests/general/TestFunctionPLPrec.xml ./tests/general/TestFunctionPL.xml ./tests/general/TestFunctionPP.xml ./tests/general/TestInteriorPoint.xml ./tests/general/TestRectanglePredicate.xml ./tests/general/TestRelateAA.xml ./tests/general/TestRelateLA.xml ./tests/general/TestRelateLL.xml ./tests/general/TestRelatePL.xml ./tests/general/TestRelateAC.xml ./tests/general/TestRelateLC.xml ./tests/general/TestRelatePA.xml ./tests/general/TestRelatePP.xml ./tests/general/TestSimple.xml ./tests/general/TestUnaryUnion.xml ./tests/general/TestUnaryUnionFloating.xml ./tests/general/TestValid.xml ./tests/general/TestValid2.xml ./tests/general/TestValid2-big.xml ./tests/general/TestWithinDistance.xml ./tests/stmlf/stmlf-cases-20061020.xml ./tests/stmlf/stmlf-cases-20061020-invalid-output.xml ./tests/stmlf/stmlf-cases-20070119.xml ./tests/robust/TestRobustOverlayFixed.xml ./tests/robust/TestRobustRelate.xml ./tests/fme.xml ./tests/TestBufferExternal.xml ./tests/TestBufferExternal2.xml ./tests/heisenbugs.xml ./tests/badguy3.xml ./tests/hole_from_shell.xml ./tests/hole_red.xml ./tests/safe/16595.xml ./tests/safe/16596.xml ./tests/safe/TestBufferJagged.xml FAIL: testrunner ================== 1 of 1 test failed ================== make[3]: * [check-TESTS] Error 1 make[3]: Leaving directory `/usr/local/src/geos-3.3.3/geos-3.3.3/tests/xmltester' make[2]: * [check-am] Error 2 make[2]: Leaving directory `/usr/local/src/geos-3.3.3/geos-3.3.3/tests/xmltester' make[1]: * [check-recursive] Error 1 make[1]: Leaving directory `/usr/local/src/geos-3.3.3/geos-3.3.3/tests' make: * [check-recursive] Error 1

[pramsey]

Same error on Centos x64 here, Centos 6.2, gcc 4.4.6

[strk]

See also #551

[strk]

For the record: this shouldn't happen because the derivate class version of the method should be invoked.

[strk]

I wonder if this is related to the GEOS_INLINE switch. Did you set custom CXX flags while building ? Does the problem still occur with current 3.3 branch ?

[dazuma]

We've just noticed this as well in production

Some info from us:

• We're running on the Amazon Linux AMI (Centos-based)
• We're running 3.3.3 currently. (We'll try upgrading to 3.3.5 and see if it persists.)
• Currently, we are able to reproduce it on pretty much any GEOSDistance_r() call, measuring between two point objects.
• There is a possibility it may be related to changes to C++ runtime libraries. We know that this was working fine earlier, and at some point (without us recompiling GEOS or making any changes to it whatsoever), we started seeing this consistent behavior, so we suspect perhaps yum updated something out from under us.
• Our compiler is gcc 4.4. We didn't use any weird switches when originally compiling geos.

Here is a stack trace that might be useful. (This is not ours, but one from someone on the spatialite mailing list who saw the same thing on 3.3.2, again calling GEOSDistance_r on two point objects.)

#0 0x0000003af26328a5 in raise () from /lib64/libc.so.6 #1 0x0000003af2634085 in abort () from /lib64/libc.so.6 #2 0x0000003af262ba1e in assert_fail_base () from /lib64/libc.so.6 #3 0x0000003af262bae0 in assert_fail () from /lib64/libc.so.6 #4 0x0000003af9eaf293 in geos::geom::GeometryComponentFilter::filter_ro(geos::geom::Geometry const*) () from /usr/lib64/libgeos-3.3.2.so #5 0x0000003af9f16095 in geos::operation::distance::DistanceOp::computeFacetDistance() () from /usr/lib64/libgeos-3.3.2.so #6 0x0000003af9f16741 in geos::operation::distance::DistanceOp::distance() () from /usr/lib64/libgeos-3.3.2.so #7 0x0000003af9f16a20 in geos::operation::distance::DistanceOp::distance(geos::geom::Geometry const*, geos::geom::Geometry const*) ()

from /usr/lib64/libgeos-3.3.2.so

#8 0x0000003afbc1151c in GEOSDistance_r () from /usr/lib64/libgeos_c.so.1

[dazuma]

Correction to the above. It looks like this may never have been "working fine earlier"; the C++ runtime library comment was likely me chasing a red herring.

I can reproduce this consistently on this platform (Amazon Linux/CentOS), and never on my other platform of choice (Mac OS X).

[strk]

This is not going to be fixed unless someone that can reproduce it is willing to debug further.

[strk]

lack of feedback, closing

[dkomisar]

I have run into this problem and have the solution.

gcc (at least some versions, I haven't checked new versions) will not create a virtual table for a class which has overridden virtual functions unless there is at least one non-inline function. The class LinearComponentExtractor is defined completely in a header file with all implicit inline functions, thus a virtual table is not generated and the base class functions are called. The base class functions do nothing except assert.

To fix this at least one of the functions should be moved into a cpp file. It may work if you just define the function later in the header after the class declaration but I'm not sure. I also think there may be other classes like this in other spots in geos.

[strk]

Good catch. For sure GCC-4.6.3 doesn't suffer from this. Would use of GEOS_DLL also fix it ? In any case, patches are welcome!

[dkomisar]

GEOS_DLL is already there. I've run into this before and haven't found a way to fix it besides what I explained.

I'm totally swamped right now but I can make a patch at some point.

[strk]

dkomisar: did you get any warning at compile time ? It would help if we knew how to have the compiler generate warnings about this...

[strk]

Also reported as #672. I guess it could be a missing non-inlined destructor in one class of the GeometryComponentFilter class hierarchy.

I don't know why but I had the impression this was fixed somewhere/somehow. Anyway being unable to reproduce myself I'd ask the reporter to try moving the ~GeometryComponentFilter implementation from include/geos/geomGeometryComponentFilter.h to ./src/geom/GeometryComponentFilter.cpp and let me know if that fixes it.

[dkomisar]

I have determined that LinearComponentExtractor is not the only subclass of GeometryComponentFilter which has this problem. There are a few others. I do not have access to the patched code currently but will soon and I will try and submit a patch.

Moving ~GeometryComponentFilter will not fix it. The problem is not with GeometryComponentFilter but with its subclasses.

I'm not sure if there was a compile warning. I believe this is a bug in older versions of gcc, don't know if it was ever intentional.

[dkomisar]

Submitted patch fixed all the instances of this problem that were problematic for me. I did notice that in top of tree (I am on 3.2.0) there is a class called GeometryExtracter which will suffer from the same problem, but since it is a template I cannot just put it in a source file. It would need to be split into a header and inline file and even then I think for the versions of gcc with this problem you'd have to explicitly instantiate each version and make sure to not include the inline file in any other source files, very easy to mess this up.

[strk]

Did you run any performance comparison to see the consequences of "offlining" this code ?

[dkomisar]

No but the original code when compiled correctly by gcc would not have actually inlined the functions since they were called through a pointer to a base class.

[strk]

Link errors with your patch applied:

../src/.libs/libgeos.so: undefined reference to `geos::geom::util::LinearComponentExtracter::getLines(geos::geom::Geometry const&, std::vector<geos::geom::LineString const*, std::allocator<geos::geom::LineString const*> >&)'
../src/.libs/libgeos.so: undefined reference to `geos::geom::util::PolygonExtracter::getPolygons(geos::geom::Geometry const&, std::vector<geos::geom::Polygon const*, std::allocator<geos::geom::Polygon const*> >&)'
../src/.libs/libgeos.so: undefined reference to `geos::geom::util::PointExtracter::getPoints(geos::geom::Geometry const&, std::vector<geos::geom::Point const*, std::allocator<geos::geom::Point const*> >&)'

gcc (Ubuntu/Linaro 4.7.3-1ubuntu1) 4.7.3

[dkomisar]

Patch for 535 - added new files to Makefile.am

[dkomisar]

Forgot to include the modified Makefile.am.

[strk]

Still no good

Wrote rev '3959' in file '../geos_svn_revision.h'
../../../../src/geom/util/LinearComponentExtracter.cpp:55:10: error: redefinition of 'geos::geom::util::LinearComponentExtracter::LinearComponentExtracter(std::vector<const geos::geom::LineString*>&)'
../../../../src/geom/util/LinearComponentExtracter.cpp:14:10: error: 'geos::geom::util::LinearComponentExtracter::LinearComponentExtracter(std::vector<const geos::geom::LineString*>&)' previously defined here
../../../../src/geom/util/LinearComponentExtracter.cpp:60:15: error: redefinition of 'static void geos::geom::util::LinearComponentExtracter::getLines(const geos::geom::Geometry&, std::vector<const geos::geom::LineString*>&)'
../../../../src/geom/util/LinearComponentExtracter.cpp:19:15: error: 'static void geos::geom::util::LinearComponentExtracter::getLines(const geos::geom::Geometry&, std::vector<const geos::geom::LineString*>&)' previously defined here
../../../../src/geom/util/LinearComponentExtracter.cpp:66:15: error: redefinition of 'void geos::geom::util::LinearComponentExtracter::filter_rw(geos::geom::Geometry*)'
../../../../src/geom/util/LinearComponentExtracter.cpp:25:15: error: 'virtual void geos::geom::util::LinearComponentExtracter::filter_rw(geos::geom::Geometry*)' previously defined here
../../../../src/geom/util/LinearComponentExtracter.cpp:72:15: error: redefinition of 'void geos::geom::util::LinearComponentExtracter::filter_ro(const geos::geom::Geometry*)'
../../../../src/geom/util/LinearComponentExtracter.cpp:31:15: error: 'virtual void geos::geom::util::LinearComponentExtracter::filter_ro(const geos::geom::Geometry*)' previously defined here
make[4]: *** [LinearComponentExtracter.lo] Error 1
make[3]: *** [all-recursive] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

[strk]

NOTE: I'm applying against trunk

[dkomisar]

I think you might need to clean out your build. I can't find any other definitions of those functions. The lines in that file it says they're located at don't exist, it's not even that long.

[strk]

It's a bug with applying the patch, leaving duplicates in LinearComponentExtracter.cpp Did you produce the patch against trunk or another branch ?

[strk]

NOTE: there's a mirror of the codebase under git, if you're comfortable with it (could be easier with a branch): ​https://github.com/libgeos/libgeos.git

[strk]

Ah, got it. It's duplicated because I applied the patch multiple times. Fixing it manually...

[strk]

See how you like r3960, in trunk (@dkomisar please also check the credit line in commit log). Not sure it's safe to backport to 3.4.x branch as it possibly changes ABI (depends on the compiler, probably)

[dkomisar]

Looks good to me. Not sure if it can be backported. Parts of the patch probably can, but I think there were some new files and such.

[janaz9]

Patches Makefile.in

[janaz9]

I had the same issue with adding this patch to the rpm spec file from the Centos src rpm. I fixed it by running automake, configure and generating a new tarball. Then I grabbed a diff between the generated and original Makefile.in file and generated another patch that unblocked the rpm build.

The patch is attached to this thread(geos-535-makefile-in.patch)

[strk]

Makefile.in is generated, you should patch Makefile.am Also, the patch doesn't seem related to the filter_ro assertion, is it ?

[gavit]

Hi all, Seems I'm getting the same error, just on a different line. Also the file seems to have been changed from .h to .cpp and it still gives this error:

ruby: GeometryComponentFilter.cpp:34: virtual void geos::geom::GeometryComponentFilter::filter_ro(const geos::geom::Geometry*): Assertion `0' failed.
Aborted

# cat /etc/*release*
CentOS release 6.6 (Final)
CentOS release 6.6 (Final)
CentOS release 6.6 (Final)
cpe:/o:centos:linux:6:GA

# yum list installed |grep geos
geos.x86_64                                       3.4.2-1.rhel6        @pgdg94  
geos-devel.x86_64                                 3.4.2-1.rhel6        @pgdg94

# yum list installed |grep gcc
gcc.x86_64                                        4.4.7-16.el6         @base    
gcc-c++.x86_64                                    4.4.7-16.el6         @base    
libgcc.x86_64                                     4.4.7-16.el6         @base

[gavit]

I tried to build from source to see if that helped, and tried a newer version of geos (geos-3.5.0). See the following [gist](​https://gist.github.com/gavit/8447bb6528c05696aec7#file-irb-L13)

[gavit]

Replying to gavit:

I tried to build from source to see if that helped, and tried a newer version of geos (geos-3.5.0). See the following [gist](​https://gist.github.com/gavit/8447bb6528c05696aec7#file-irb-L13)

Same issue with gcc (GCC) 4.7.2

[gist](​https://gist.github.com/gavit/8447bb6528c05696aec7#file-irb-with-geos-compiled-with-4-7-2-L13)

[gavit]

Replying to gavit:

Replying to gavit:

I tried to build from source to see if that helped, and tried a newer version of geos (geos-3.5.0). See the following [gist](​https://gist.github.com/gavit/8447bb6528c05696aec7#file-irb-L13)

Same issue with gcc (GCC) 4.7.2

[gist](​https://gist.github.com/gavit/8447bb6528c05696aec7#file-irb-with-geos-compiled-with-4-7-2-L13)

make test seems to pass: [gist](​https://gist.github.com/gavit/8447bb6528c05696aec7)

[strk]

Ticket retargeted after milestone deleted

[opoplawski]

I'm running into this with django's geos support as well. Would be great to get fixed.

[strk]

Sounds like a compiler bug to me

[strk]

Ticket retargeted after milestone closed

[strk]

Ticket retargeted after milestone closed

[robe]

I'm closing this out since GCCs have changed over the years and I suspect this is no longer and issue. Feel free to open if someone can replicate.