Opened 8 years ago

Closed 8 years ago

Last modified 8 years ago

#1799 closed defect (fixed)

Passing zero as max_length to ST_Segmentize() causes crash

Reported by: skwash Owned by: pramsey
Priority: blocker Milestone: PostGIS 1.5.4
Component: postgis Version: 1.5.X
Keywords: Cc:

Description

Running something like the following causes server process to max out the CPU and seems to require a kill -9 to stop the process (crashing postgres entirely).

SELECT ST_Segmentize(ST_MakeLine(ST_MakePoint(0,0), ST_MakePoint(1,1)), 0);

It doesn't really make sense to pass zero, but I'm sure someone else at some point will try it with worse results than what I caused myself today. ;) A simple param validation to catch this would probably be useful to ensure idiots (like me!) don't do this on accident.

Change History (7)

comment:1 Changed 8 years ago by strk

Milestone: PostGIS 2.0.1PostGIS 1.5.4
Priority: mediumblocker
Version: 2.0.x1.5.X

It happens in 1.5.4 too !

comment:2 Changed 8 years ago by strk

BTW: what do we want in output ? An exception ?

comment:3 Changed 8 years ago by strk

I shall notice that even a non-zero but very small distance argument (like 1e-8) suffer by the same out-of-memory and uninterruptability problem.

comment:4 Changed 8 years ago by strk

Resolution: fixed
Status: newclosed

r9711 in 1.5 branch and r9712 in trunk protect from max_length = 0.

Nothing changes for tiny distances and uninterruptability.

comment:5 Changed 8 years ago by strk

For the record: I tried and ST_Segmentize _can_ be interrupted.

comment:6 Changed 8 years ago by strk

Uhm, I was wrong, it is the instrumentation of NOTICE prints that would turn the function into an interruptable one. Simple allocations and deallocations don't check for interrupts.

comment:7 Changed 8 years ago by strk

I filed #1802 for interruptability

Note: See TracTickets for help on using tickets.