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)
Change History (10)
comment:1 by , 16 years ago
| Version: | SVN → gis |
|---|
by , 16 years ago
| Attachment: | geom_string_from_geom.patch added |
|---|
comment:2 by , 16 years ago
| milestone: | → 1.0 beta |
|---|---|
| Triage Stage: | Unreviewed → Accepted |
comment:3 by , 16 years ago
| milestone: | 1.0 beta |
|---|---|
| Needs documentation: | set |
| Patch needs improvement: | set |
follow-up: 5 comment:4 by , 16 years ago
| Triage Stage: | Accepted → Design 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.
follow-up: 6 comment:5 by , 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.
comment:6 by , 16 years ago
| Owner: | changed from to |
|---|---|
| Triage Stage: | Design decision needed → Accepted |
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 , 16 years ago
| Resolution: | → worksforme |
|---|---|
| Status: | new → closed |
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 , 16 years ago
| Resolution: | worksforme |
|---|---|
| Status: | closed → reopened |
Should be noted this was for 64-bit CentOS -- which is why I could not reproduce.
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_ptype wasn't specified (as noted in the comments) because, IIRC, it made it difficult to free the memory allocated in the GEOS library withlibc.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.