Opened 7 years ago

Closed 3 months ago

#535 closed defect (wontfix)

GeometryComponentFilter::filter_ro: Assertion `0' failed

Reported by: aaronharris Owned by: pramsey
Priority: major Milestone: 3.6.3
Component: Build/Install Version: 3.4.2
Severity: Unassigned Keywords:
Cc: dkomisar, gavit, opoplawski

Description

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

Attachments (2)

geos-535.patch (14.4 KB) - added by dkomisar 5 years ago.
Patch for 535 - added new files to Makefile.am
geos-535-makefile-in.patch (1.9 KB) - added by janaz9 5 years ago.
Patches Makefile.in

Download all attachments as: .zip

Change History (46)

comment:1 Changed 7 years ago by pramsey

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

comment:2 Changed 6 years ago by strk

See also #551

comment:3 Changed 6 years ago by strk

Summary: error running make checkGeometryComponentFilter::filter_ro: Assertion `0' failed

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

comment:4 Changed 6 years ago by strk

Milestone: 3.3.43.3.5

comment:5 Changed 6 years ago by 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 ?

comment:6 Changed 6 years ago by strk

Milestone: 3.3.53.3.6

comment:7 Changed 6 years ago by 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

comment:8 Changed 6 years ago by 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).

comment:9 Changed 6 years ago by strk

Component: DefaultBuild/Install
Milestone: 3.3.63.3.7
Owner: changed from geos-devel@… to pramsey

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

comment:10 Changed 6 years ago by strk

Resolution: wontfix
Status: newclosed

lack of feedback, closing

comment:11 Changed 5 years ago by dkomisar

Cc: dkomisar added
Resolution: wontfix
Status: closedreopened

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.

comment:12 Changed 5 years ago by strk

Milestone: 3.3.73.4.3

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!

comment:13 Changed 5 years ago by 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.

comment:14 Changed 5 years ago by 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...

comment:15 Changed 5 years ago by 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.

comment:16 Changed 5 years ago by 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.

comment:17 Changed 5 years ago by 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.

comment:18 Changed 5 years ago by strk

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

comment:19 Changed 5 years ago by 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.

comment:20 Changed 5 years ago by 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

Changed 5 years ago by dkomisar

Attachment: geos-535.patch added

Patch for 535 - added new files to Makefile.am

comment:21 Changed 5 years ago by dkomisar

Forgot to include the modified Makefile.am.

comment:22 Changed 5 years ago by 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

comment:23 Changed 5 years ago by strk

NOTE: I'm applying against trunk

comment:24 Changed 5 years ago by 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.

comment:25 Changed 5 years ago by strk

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

comment:26 Changed 5 years ago by 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

comment:27 Changed 5 years ago by strk

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

comment:28 Changed 5 years ago by 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)

comment:29 Changed 5 years ago by 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.

Changed 5 years ago by janaz9

Attachment: geos-535-makefile-in.patch added

Patches Makefile.in

comment:30 in reply to:  22 Changed 5 years ago by 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)

comment:31 Changed 5 years ago by strk

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

comment:32 Changed 5 years ago by strk

Resolution: fixed
Status: reopenedclosed

comment:33 Changed 3 years ago by 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
Last edited 3 years ago by gavit (previous) (diff)

comment:34 Changed 3 years ago by gavit

Cc: gavit added
Resolution: fixed
Status: closedreopened
Version: 3.3.33.4.2

comment:35 Changed 3 years ago by 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) The error is probably related to me not being able to update the gem (yet).

Last edited 3 years ago by gavit (previous) (diff)

comment:36 in reply to:  35 ; Changed 3 years ago by 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)

comment:37 in reply to:  36 Changed 3 years ago by 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)

comment:38 Changed 2 years ago by strk

Milestone: 3.4.33.6.1

Ticket retargeted after milestone deleted

comment:39 Changed 2 years ago by opoplawski

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

comment:40 Changed 2 years ago by opoplawski

Cc: opoplawski added

comment:41 Changed 2 years ago by strk

Sounds like a compiler bug to me

comment:42 Changed 21 months ago by strk

Milestone: 3.6.13.6.2

Ticket retargeted after milestone closed

comment:43 Changed 16 months ago by strk

Milestone: 3.6.23.6.3

Ticket retargeted after milestone closed

comment:44 Changed 3 months ago by robe

Resolution: wontfix
Status: reopenedclosed

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.

Note: See TracTickets for help on using tickets.