Opened 11 years ago
Closed 11 years ago
Last modified 11 years ago
#1799 closed defect (fixed)
Passing zero as max_length to ST_Segmentize() causes crash
|Reported by:||skwash||Owned by:||pramsey|
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 by , 11 years ago
|Milestone:||PostGIS 2.0.1 → PostGIS 1.5.4|
|Priority:||medium → blocker|
|Version:||2.0.x → 1.5.X|
comment:2 by , 11 years ago
BTW: what do we want in output ? An exception ?
comment:3 by , 11 years ago
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 by , 11 years ago
|Status:||new → closed|
comment:5 by , 11 years ago
For the record: I tried and ST_Segmentize _can_ be interrupted.
comment:6 by , 11 years ago
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 by , 11 years ago
I filed #1802 for interruptability
It happens in 1.5.4 too !