ST_ClusterDBSCAN garden crasher

[robe]

I haven't had a chance to dissect this or even check if it fails in lower PostgreSQL versions.

I'm running:

PostgreSQL 9.6beta4, compiled by Visual C++ build 1800, 64-bit POSTGIS="2.3.0dev r15043" GEOS="3.5.0-CAPI-1.9.0 r4090" SFCGAL="1.3.0" PROJ="Rel. 4.9.1, 04 March 2015" GDAL="GDAL 2.1.0, released 2016/04/25" LIBXML="2.7.8" LIBJSON="0.12" RASTER

Query that crashes:

SELECT ST_ClusterDBSCAN(foo1.the_geom, 20.1, 5)OVER()  As result
							FROM ((SELECT geom  As the_geom
FROM (VALUES ( ST_GeomFromEWKT('SRID=4326;POLYGONM((-71.1319 42.2503 1,-71.132 42.2502 3,-71.1323 42.2504 -2,-71.1322 42.2505 1,-71.1319 42.2503 0))') ),
	( ST_GeomFromEWKT('SRID=4326;POLYGONM((-71.1319 42.2512 0,-71.1318 42.2511 20,-71.1317 42.2511 -20,-71.1317 42.251 5,-71.1317 42.2509 4,-71.132 42.2511 6,-71.1319 42.2512 30))') ) ) As g(geom))) As foo1 LIMIT 3;

Back trace just

#0  0x00000000696dcb4a in postgis-2.3!ST_ClusterDBSCAN ()
   from C:\ming64gcc48\projects\postgresql\rel\pg9.6w64gcc48edb\lib\postgis-2.3.dll
#1  0x000000014015358f in postgres!WinGetFuncArgCurrent ()
#2  0x0000000140151f0e in postgres!ExecWindowAgg ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

[robe]

This may be a windows specific issue. I tried this example in plain old mingw environment so downgrading from blocker to critical.

PostgreSQL 9.6beta4 on x86_64-w64-mingw32, compiled by gcc.exe (x86_64-win32-seh-rev1, Built by MinGW-W64 project) 4.8.3, 64-bit POSTGIS="2.3.0dev r15043" GEOS="3.5.0-CAPI-1.9.0 r4088" PROJ="Rel. 4.9.1, 04 March 2015" GDAL="GDAL 2.1.0, released 2016/04/25" LIBXML="2.7.8" LIBJSON="0.12" RASTER

and it returns:

0
1

Which is a bummer since I get so much more info when it crashes under mingw.

Dan if you could give it a try on your platform and see if you can trigger a crash. I'm going to try next in my 9.5 and 9.4 windows instances

[robe]

Crashes in 9.5 also so not 9.6 specific.

[dbaston]

Even when it "works" in mingw it's giving incorrect results (both rows should be null since r14928).

[robe]

dbaston,

Good news, I must have been running an earlier version in my mingw install, because now it crashes too under mingw. I think my windows was running latest build from winnie, and I didn't think to compare the postgis full version.

So that means this issue was probably introduced in that commit which explains why crash tests I've done in past didn't trigger a crash. Does this cash on your system?

I'll commit a bug trace shortly.

[robe]

Here is backtrace for

POSTGIS="2.3.0dev r15050" GEOS="3.5.0-CAPI-1.9.0 r4088" PROJ="Rel. 4.9.1, 04 March 2015" GDAL="GDAL 2.1.0, released 2016/04/25" LIBXML="2.7.8" LIBJSON="0.12" RASTER PostgreSQL 9.6beta4 on x86_64-w64-mingw32, compiled by gcc.exe (x86_64-win32-seh-rev1, Built by MinGW-W64 project) 4.8.3, 64-bit

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 23144.0x52e8]
0x00000000696e792c in ST_ClusterDBSCAN ()
   from C:\ming64gcc48\projects\postgresql\rel\pg9.6w64gcc48\lib\postgis-2.3.dll
(gdb) bt
#0  0x00000000696e792c in ST_ClusterDBSCAN ()
   from C:\ming64gcc48\projects\postgresql\rel\pg9.6w64gcc48\lib\postgis-2.3.dll
#1  0x00000000005afc9f in eval_windowfunction (perfuncstate=0xe10b978,
    result=0xe10b938, isnull=0xe10b958 "", winstate=0xe10a2e0,
    winstate=0xe10a2e0) at nodeWindowAgg.c:1005
#2  0x00000000005b0fd7 in ExecWindowAgg (winstate=winstate@entry=0xe10a2e0)
    at nodeWindowAgg.c:1724
#3  0x000000000058b218 in ExecProcNode (node=node@entry=0xe10a2e0)
    at execProcnode.c:507
#4  0x00000000005a2810 in ExecLimit (node=node@entry=0xe109fa0)
    at nodeLimit.c:91
#5  0x000000000058b188 in ExecProcNode (node=node@entry=0xe109fa0)
    at execProcnode.c:531
#6  0x00000000005871c5 in ExecutePlan (dest=0xe147688,
    direction=<optimized out>, numberTuples=0, sendTuples=1 '\001',
    operation=CMD_SELECT, use_parallel_mode=<optimized out>,
    planstate=0xe109fa0, estate=0xe109e88) at execMain.c:1567
#7  standard_ExecutorRun (queryDesc=0xe0f86e8, direction=<optimized out>,
    count=0) at execMain.c:338
#8  0x00000000006b1fe6 in PortalRunSelect (portal=portal@entry=0xe0ffe38,
    forward=forward@entry=1 '\001', count=0, count@entry=43643472,
    dest=dest@entry=0x0) at pquery.c:948
#9  0x00000000006b3686 in PortalRun (portal=0x299ee90,
    portal@entry=0xe0ffe38, count=43643472, count@entry=2147483647,
    isTopLevel=isTopLevel@entry=0 '\000', dest=0x0, dest@entry=0xe147688,
    altdest=altdest@entry=0xe147688, completionTag=0x299f210 "",
    completionTag@entry=0x400000001d7 <error: Cannot access memory at address 0x400000001d7>) at pquery.c:789
#10 0x00000000006b0e54 in exec_simple_query (
    query_string=0x100000000000000 <error: Cannot access memory at address 0x100000000000000>) at postgres.c:1094
#11 PostgresMain (argc=<optimized out>, argv=argv@entry=0x1093c0,
    dbname=0x18001700160015 <error: Cannot access memory at address 0x18001700160015>, username=<optimized out>) at postgres.c:4074
#12 0x0000000000647aad in BackendRun (port=0x299f400) at postmaster.c:4262
#13 SubPostmasterMain (argc=argc@entry=3, argv=argv@entry=0x307e80)
    at postmaster.c:4752
#14 0x0000000000803d68 in main (argc=3, argv=0x307e80) at main.c:205

[robe]

Given that it now crashes my mingw, upgrading this to blocker.

[robe]

I have reduced this to a much simpler case that still crashes:

SELECT ST_ClusterDBSCAN( ST_Point(1,1), 20.1, 5) OVER();

[dbaston]

Thanks for the simpler case. I can now reproduce the crash and I'm pretty sure I know what's going on. Should be able to patch in a couple of days.

[robe]

Dan,

You think you can fix before Tuesday? If not I'll go ahead and do the beta release tomorrow (or Monday as planned). If so I can wait a bit till you have this fixed.

[dbaston]

Yes, I can fix before Tuesday.

[robe]

Looks like your last commit at r15057 fixed this. no more garden crashing. Feel free to reopen if you still think an issue.