Ticket #1799 (closed defect: fixed)

Opened 13 months ago

Last modified 13 months ago

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

Changed 13 months ago by strk

  • priority changed from medium to blocker
  • version changed from 2.0.x to 1.5.X
  • milestone changed from PostGIS 2.0.1 to PostGIS 1.5.4

It happens in 1.5.4 too !

Changed 13 months ago by strk

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

Changed 13 months 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.

Changed 13 months ago by strk

  • status changed from new to closed
  • resolution set to fixed

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

Nothing changes for tiny distances and uninterruptability.

Changed 13 months ago by strk

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

Changed 13 months 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.

Changed 13 months ago by strk

I filed #1802 for interruptability

Note: See TracTickets for help on using tickets.