Debug symbols for Mapguide 2.5.1 Centos packages

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Debug symbols for Mapguide 2.5.1 Centos packages

Gabriele Monfardini
Hi all,

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
/usr/local/mapguideopensource-2.5.1/lib/libMgGeometry-2.5.1.so


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
Administrator
 Error: Resource was not found:
Session:857722e8-3245-11e3-8000-5254006ae79a_en_MTI3LjAuMC4x0AFC0AFB0AFA//edifici.Map
 StackTrace:
  - MgResourceServiceHandler.ProcessOperation() line 80 file
ResourceServiceHandler.cpp
  - MgOpGetResourceData.Execute() line 124 file OpGetResourceData.cpp
  -
MgServerResourceService.GetResourceData(Id=Session:857722e8-3245-11e3-8000-5254006ae79a_en_MTI3LjAuMC4x0AFC0AFB0AFA//edifici.Map
   DataName=RuntimeData    Tags=) line 1869 file ServerResourceService.cpp
  - MgApplicationRepositoryManager.GetResourceData() line 1246 file
ApplicationRepositoryManager.cpp
  - MgResourceContentManager.GetDocument() line 590 file
ResourceContentManager.cpp
  - MgResourceDefinitionManager.GetDocument
(857722e8-3245-11e3-8000-5254006ae79a_en_MTI3LjAuMC4x0AFC0AFB0AFA.dbxml)()
line 476 file ResourceDefinitionManager.cpp
  - MgResourceDefinitionManager.GetDocument() line 467 file
ResourceDefinitionManager.cpp

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
Administrator
 Error: A length exception occurred.
        basic_string::_S_create
 StackTrace:
  - 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?

Regards,

Gabriele Monfardini
_______________________________________________
mapguide-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals
Reply | Threaded
Open this post in threaded view
|

Re: Debug symbols for Mapguide 2.5.1 Centos packages

Jackie Ng
>> 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)

- Jackie