[postgis-users] Core dumps

[Peter Hopfgartner]

Hi Mark!

>On 04/02/11 07:20, Peter Hopfgartner wrote:
>
>> We do have code dumps enabled on our developement servers and, from
>time to time, some PostgreSQL/PostGIS process dumps core.
>> Could some useful feedback be provided to the developers from these
>dumps? Is the back trace enough, like the following:
>>
>> Program terminated with signal 11, Segmentation fault.
>> #0  0x00000035eee79c00 in strncat () from /lib64/libc.so.6
>> (gdb) bt
>> #0  0x00000035eee79c00 in strncat () from /lib64/libc.so.6
>> #1  0x00002b9176d04282 in lwmessage_truncate ()
>>     from /usr/lib64/pgsql/postgis-1.5.so
>> #2  0x00002b9176cc95a1 in pg_parser_errhint ()
>>     from /usr/lib64/pgsql/postgis-1.5.so
>> #3  0x00002b9176ccf2eb in LWGEOM_in () from
>/usr/lib64/pgsql/postgis-1.5.so
>> #4  0x000000000068b1fd in InputFunctionCall ()
>> #5  0x000000000068be6a in OidInputFunctionCall ()
>> #6  0x00000000004dfead in coerce_type ()
>> #7  0x00000000004e0733 in coerce_to_target_type ()
>> #8  0x00000000004e1d29 in transformAssignedExpr ()
>> #9  0x00000000004e1ea5 in updateTargetListEntry ()
>> #10 0x00000000004b8627 in transformStmt ()
>> #11 0x00000000004bab0e in parse_analyze ()
>> #12 0x00000000005da07c in pg_analyze_and_rewrite ()
>> #13 0x00000000005da7f8 in ?? ()
>> #14 0x00000000005db55b in PostgresMain ()
>> #15 0x00000000005b1d8d in ?? ()
>> #16 0x00000000005b2b3c in PostmasterMain ()
>> #17 0x00000000005603be in main ()
>>
>>
>> Regards,
>>
>> Peter
>
>Right, so these point to a bug in the parser position calculation on the 
>WKT/WKB input for a particular (and in fact, only for an invalid) 
>geometry. If you can find the offending geometries and post the WKT/WKB 
>here, we should be able to fix this reasonably easily.
>

Unfortunatly it i snot possible in this case. I have core dumping enabled on the server, where multiple developers have testing instances of multiple applications and I do have a cron job, that every night advises me, if there are core dumps on the disk. But sometimes, like in this case, it is almost impossible that I can isolate a decent test case, since I do not even know how the query, that lead to the segmentation fault looks like. If I have all the necessary info, I usually try hard to isolate a decent test case. The point is, is a back trace useful, even without context like query and data?
>
>ATB,
>
>Mark.
>
>-- 
>Mark Cave-Ayland - Senior Technical Architect
>PostgreSQL - PostGIS
>Sirius Corporation plc - control through freedom
>http://www.siriusit.co.uk
>t: +44 870 608 0063
>
>Sirius Labs: http://www.siriusit.co.uk/labs

Regards,

Peter
 
R3 GIS Srl - GmbH
http://www.r3-gis.com