Code

Opened 6 years ago

Closed 6 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: UI/UX:

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 6 years ago.

Download all attachments as: .zip

Change History (10)

comment:1 Changed 6 years ago by anonymous

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Version changed from SVN to gis

Changed 6 years ago by santiago_aguiar

comment:2 Changed 6 years ago by Simon Greenhill

  • milestone set to 1.0 beta
  • Triage Stage changed from Unreviewed to Accepted

comment:3 Changed 6 years ago by jbronn

  • milestone 1.0 beta deleted
  • 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 follow-up: Changed 6 years ago by jbronn

  • Triage Stage changed from Accepted to 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.

comment:5 in reply to: ↑ 4 ; follow-up: Changed 6 years ago by anonymous

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 in reply to: ↑ 5 Changed 6 years ago by jbronn

  • Owner changed from nobody to jbronn
  • Triage Stage changed from Design decision needed to 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 Changed 6 years ago by jbronn

  • Resolution set to worksforme
  • Status changed from new to 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 Changed 6 years ago by jbronn

  • Resolution worksforme deleted
  • Status changed from closed to reopened

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

comment:9 Changed 6 years ago by jbronn

  • Resolution set to duplicate
  • Status changed from reopened to closed

Duplicate of #9747.

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.