Opened 16 years ago

Closed 16 years ago

#7764 closed (duplicate)

[gis] Segfault on django.contrib.gis.geos.prototypes.errcheck.check_string

Reported by: santiago_aguiar Owned by: jbronn
Component: GIS Version: gis
Severity: Keywords: segfault geos string_at
Cc: Triage Stage: Accepted
Has patch: yes Needs documentation: yes
Needs tests: no Patch needs improvement: yes
Easy pickings: no UI/UX: no

Description

Running GeoDjango gets me a segmentation fault on django.contrib.gis.geos.prototypes.errcheck:49 when doing string_at(result).

Following guidelines from http://trac.gispython.org/projects/PCL/ticket/129, I applied the attached patch and the problem disappeared. I'm not familiar enough with GEOS to know if the change should perform what is needed from string_from_geom. In case it is, additional changes should be performed to avoid using string_at.

Version:
CentOS 5.2
django_gis: r7928
postgis: 1.3.2
geos: 3.0.0
Running under apache + mod_python

Attachments (1)

geom_string_from_geom.patch (456 bytes ) - added by santiago_aguiar 16 years ago.

Download all attachments as: .zip

Change History (10)

comment:1 by anonymous, 16 years ago

Version: SVNgis

by santiago_aguiar, 16 years ago

Attachment: geom_string_from_geom.patch added

comment:2 by Simon Greenhill, 16 years ago

milestone: 1.0 beta
Triage Stage: UnreviewedAccepted

comment:3 by jbronn, 16 years ago

milestone: 1.0 beta
Needs documentation: set
Patch needs improvement: set

Can you provide the situation in which the segmentation fault occurs? An example case would be nice, or the steps used to reproduce would be nice (e.g., does this happen every time, or randomly, on startup, etc.?).

This patch introduces a serious memory leak and will not be applied in its current form. There were reasons why the c_char_p type wasn't specified (as noted in the comments) because, IIRC, it made it difficult to free the memory allocated in the GEOS library with libc.free. I'll re-research into whether it's possible to specify the response type and be able to free the memory address.

Ticket triagers: please let the branch maintainers handle the setting of milestones and tickets for version 1.0.

comment:4 by jbronn, 16 years ago

Triage Stage: AcceptedDesign decision needed

Are you running Apache in threaded mode? The GEOS library is not thread safe -- I have a hunch this may be the problem.

in reply to:  4 ; comment:5 by anonymous, 16 years ago

Replying to jbronn:

Are you running Apache in threaded mode? The GEOS library is not thread safe -- I have a hunch this may be the problem.

The referred ticket also suggested this option, and also pointer to a ctypes bug. However, I tracked the issue running httpd -X so I could check where the segfault was happening, and in that case I'm running only one worker... I don't see how a threading issue could be the cause here.

It happened always, at the same spot, after performing a SELECT from the DB and trying to render the geom as a string (a POINT in this case). I tracked the issue using the admin interface (tying to avoid problems specific to my app views, in which the problem also appeared) and gdb. I'm going to see if I can put some more time in this and I'll report back.

The guys at gispython implemented another approach, which I didn't like much.

I'm running python 2.4 with ctypes 1.0.0.

in reply to:  5 comment:6 by jbronn, 16 years ago

Owner: changed from nobody to jbronn
Triage Stage: Design decision neededAccepted

It happened always, at the same spot, after performing a SELECT from the DB and trying to render the geom as a string (a POINT in this case). I tracked the issue using the admin interface (tying to avoid problems specific to my app views, in which the problem also appeared) and gdb. I'm going to see if I can put some more time in this and I'll report back.

If it's not happening at random, then can you provide a test case (code & data) so that I may reproduce? Preferably outside of Apache, but if that's not possible it's OK. I've got a CentOS 5.2 VMWare image ready for just this purpose, and I'd be able to get to the root this a lot faster.

Another thought is that I know I've experienced other problems with ctypes 1.0.0 (it has bugs -- I can't remember offhand the specific problems I had). Try installing the latest version (1.0.2) and see if it helps.

comment:7 by jbronn, 16 years ago

Resolution: worksforme
Status: newclosed

Works for me. I've tried my hardest and cannot reproduce this bug.

I've created a VM that is running CentOS 5.2. The following packages are installed:

Binary: Python 2.4.3, Apache 2.2.3, mod_python 3.2.8, PostgreSQL 8.1, ctypes 1.0.0

Source: GEOS 3.0.0, PROJ.4 4.6.0, GDAL 1.5.2, psycopg 2.0.7, PostGIS 1.3.2

All GEOS and GDAL model tests pass; the entire [browser:django/branches/gis/django/contrib/gis/tests GeoDjango test suite passes]. Moreover, I installed my project used for the tutorial at Where 2.0. The where2 project has 68K PointField models (tabc.Location), 8.8K of MultiLineString (harris.Edge) models, and 58K MultiPolygon (census.State, census.County, texas.Neighborhood, and texas.Zip). All data imported fine and views worked as expected with no segmentation faults encountered. Finally, I was able to view and edit all models in the geographic admin (available in SVN since this morning). Both admin and views were served up via Apache/mod_python.

I had a lot of difficulty getting Apache/mod_python working. Specifically, Apache wouldn't couldn't find the project settings file despite a globally set PYTHONPATH, correct permissions, and a correctly set PythonPath directive in httpd.conf -- however, no segfaults. After I disabled SELinux, it was smooth sailing -- could this be your problem?

Unless I'm provided with a reproducible test case, this ticket is closed.

comment:8 by jbronn, 16 years ago

Resolution: worksforme
Status: closedreopened

Should be noted this was for 64-bit CentOS -- which is why I could not reproduce.

comment:9 by jbronn, 16 years ago

Resolution: duplicate
Status: reopenedclosed

Duplicate of #9747.

Note: See TracTickets for help on using tickets.
Back to Top