I was stress testing Mapguide 2.5.1 on Centos 6 using OGR provider and a
recompiled libgdal 1.9 to support PostgreSQL.
I'am experiencing a quite good performance level but also randomic crashes.
Trying to debug it with gdb I've find that at least one time the crash
seems to have happened inside GEOS library.
0x01d8aa5e in geos::IntervalSize::isZeroWidth(double, double) () from
Unfortunately I don't have debug symbols for Mapguide libraries.
Some other times gdb stack trace is empty so the crash probably happened
inside Mapguide code.
In Error.log I'm seeing the following type of Errors
<2013-10-11T09:20:05> -1613595792 10.1.1.46
Error: Resource was not found:
- MgResourceServiceHandler.ProcessOperation() line 80 file
- MgOpGetResourceData.Execute() line 124 file OpGetResourceData.cpp
DataName=RuntimeData Tags=) line 1869 file ServerResourceService.cpp
- MgApplicationRepositoryManager.GetResourceData() line 1246 file
- MgResourceContentManager.GetDocument() line 590 file
line 476 file ResourceDefinitionManager.cpp
- MgResourceDefinitionManager.GetDocument() line 467 file
I'm on 32 bit so I've set short timing for session expiration (180s) and
for session expiration check (every 60s), otherwise out-of-memory errors
begin to appear if many sessions are created in a small time.
This error is not fatal, just a very small number of requests failed.
The number of sessions, evaluated counting the number of dbxml files in
Repositories/Sessions, lies in the interval [200-350].
Is some thread trying to access an already cleared session dbxml?
<2013-10-11T09:40:08> -1477227664 10.1.1.46
Error: A length exception occurred.
- MgOperationThread.ProcessOperation() line 437 file OperationThread.cpp
This error is a bit weird. After this error sometimes Mapguide continued,
sometimes it crashed, due to this error or to some other error that was not
written in the Error log.
Memory consumption during stress test is quite high (over 1.5GB RAM, I
don't think MapGuide 32bit is able to user more then 2GB) but stable.
So these are my questions:
1. Are available debug packages for Centos?
2. Which version of GEOS do MapGuide use? I presume an internal one, not
Centos native one.
3. Why in basic_string::_S_create the stack trace seems to be
incomplete? I mean MgOperationThread.ProcessOperation afaik is the entry
point of every operation but does not do any actual work. Did the exception
really happened inside this method?
Re: Debug symbols for Mapguide 2.5.1 Centos packages
>> 1. Are available debug packages for Centos?
Nope, I only have enough build resources to produce release-only builds for Centos 6.x and Ubuntu 12.04 LTS. We're also really short on developer expertise to look at any Linux-specific issues.
>> 2. Which version of GEOS do MapGuide use? I presume an internal one, not
>> Centos native one.
GEOS 2.2.0 under MapGuide's oem tree. Yes, it's really ancient. Yes, we should probably upgrade this.
>> 3. Why in basic_string::_S_create the stack trace seems to be
>> incomplete? I mean MgOperationThread.ProcessOperation afaik is the entry
>> point of every operation but does not do any actual work. Did the exception
>> really happened inside this method?
I do recall some time ago that there was a wholesale change in the server codebase to how std::string objects were being assigned due to some thread safety issue in Linux. Maybe we left out a spot? (idea pulled out of thin air)