[Mapserver-users] mod_perl segfaults

[Lowell Filak]

The following message was sent by Eric Bridger <eric at gomoos.org> on 16
Jun 2004 10:04:06 -0400.

> On Tue, 2004-06-15 at 10:44, Lowell Filak wrote:
> > The following message was sent by Robert Marcus Evans
> > <rob at ert.dyndns.org> on Tue, 15 Jun 2004 10:24:56 -0400.
> > 
> > > Actually, we're using mod_perl/HTML::Mason in one place, and straight
> > cgi's
> > > in another. The CGI's don't ever seem to crash, whereas the mason is
> > > unstable. I don't think it would be a threading issue, as I create a
> > new map
> > > object for each request. However, it would be possible for multiple
> > > simultaneous map objects to exist for the same base file. Furthermore,
> > I use
> > > the static .map file as a base, and draw different dynamic objects
on top,
> > > depending on the request. I don't explicitly kill the map objects (is
> > there
> > > some kind of locking mechanism?), but then they're in a lexical
scope and
> > > should be garbage collected. You guys seem to be suggesting that if I
> > used a
> > > static map object for each apache process, the problem would still
exist.
> > > Anyone have any other ideas?
> > > 
> > > -rob
> > > 
> > > Lowell Filak wrote this on Tue, Jun 15, 2004 at 09:47:38AM -0400:
> > > > The following message was sent by covad at ert.dyndns.org on Mon,
14 Jun
> > > > 2004 15:30:43 -0400.
> > > > 
> > > > > I'm getting errors like the following:
> > > > > 
> > > > > [Mon Jun 14 14:22:49 2004] [notice] child pid 19412 exit signal
> > > > Segmentation fault (11)
> > > > > 
> > > > > in my apache error log, but only intermittently. The site is
> > usable, but
> > > > > craps out ~25% of the time.
> > > > > 
> > > > > I'm running perl mapscript 4.2.0, apache 1.3.31, and mod_perl
1.29.
> > > > > 
> > > > > Has anyone else seen behavior like this?
> > > > > 
> > > > > Would rolling back to mapscript 4.0 help?
> > > > > 
> > > > > Thanks,
> > > > > 
> > > > > -rob
> > > > > 
> > > > 
> > > > Rob
> > > > 
> > > > As Sean mentioned before - it is probably due to multiple
requests into
> > > > the same map/mapObj.
> > > > Starting in 4.2 it should be safe to clone the map to avoid this
but it
> > > > does require more testing then what has been done.
> > > > If that doesn't work I know that GOMOOS (currently very busy so
I'm not
> > > > sure they will reply) currently uses mod_perl but opens a new
map for
> > > > each request to ensure that two requests do not conflict.
> > > > 
> > > > Lowell
> > > 
> > 
> > Rob
> > 
> > Until I have a chance to switch our server to mod_perl I can't reproduce
> > the issue but I meant to suggest that you Do use a static map object for
> > each request to try and eliminate the problem.
> > Dynamic objects being drawn via MapScript only change the map object and
> > not the map file so it sounds like your expecting the map object to not
> > be shared between requests but in fact it is.?
> > You do not need to explicitly kill map objects and as long as seperate
> > requests are not sharing the same map object the process of 'reading'
> > the same static map file is read-only so no locking should be
> > required... unless your doing a saveMapContext.?
> 
> I do see this type of error frequently in our development server Apache
> logs:
> > [Mon Jun 14 14:22:49 2004] [notice] child pid 19412 exit signal
> > > > Segmentation fault (11)
> 
> in fact as recently as last Monday. Unfortunately I cannot remember what
> the circumstances were and I have not been able to reproduce it. When it
> happens again (it will) and my memory gets jogged I'll report the
> circumstances.
> 
> We never see this in our production server or even in out development
> staging server.
> 
> My guess is that it has nothing to do with mod_perl or thread safety
> issues since you load your map file for each request (as we do). There
> is no issue in multiple processes reading the map file simultaneously.
> 
> Eric
> 


Thanks for the info Eric.
Obviously this is good & bad until we have a bug nailed down.
Can anyone provide some good steps to reproduce this so a bug can be
filed if necessary?

Thanks.

Lowell