<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=utf-8">
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META NAME="Generator" CONTENT="MS Exchange Server version 6.0.6618.4">
<TITLE>[fdo-internals] gcc mt_alloc related bugs? </TITLE>
</HEAD>
<BODY dir=ltr>
<DIV>Yikes! I think a repressed memory is coming back. I gave up on getting my
x64 MapGuide build to run after failing to resolve such an error in Xalan
strings. I was using gcc 3.4 also.</DIV>
<DIV> </DIV>
<DIV>Traian</DIV>
<DIV> </DIV>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
<DIV><FONT size=2>-----Original Message----- <BR><B>From:</B>
fdo-internals-bounces@lists.osgeo.org on behalf of Frank Warmerdam
(External) <BR><B>Sent:</B> Fri 2/16/2007 3:26 AM <BR><B>To:</B> FDO Internals
Mail List <BR><B>Cc:</B> <BR><B>Subject:</B> [fdo-internals] gcc mt_alloc
related bugs? <BR><BR></FONT></DIV>
<P><FONT size=2>Folks,<BR><BR>I mentioned a couple days ago that I was still
seeing crashes under<BR>some circumstances after my 64bit fixes. I have
spent more hours than<BR>I wish to contemplate digging into these crashes and
have not come up<BR>with a particular satisfying answer.<BR><BR>The crashes
seemed to be related to corruption of the freelist<BR>datastructures
maintained by the mt_alloc allocator for stl vector<BR>objects (ie. the
XalanDOMString).<BR><BR>On Linux with glibc it seems you can define the
environment variable<BR>GLIBCXX_FORCE_NEW to force a new and delete to be done
each time stl<BR>container allocate or free memory, instead of using the
mt_alloc pool<BR>allocator. This seems to avoid the problem. I
*thought* when running<BR>in this mode I would finally be able to find the bug
in the FDO code<BR>using valgrind, but things run perfectly
clean!<BR><BR>Based on a variety of googling, I am now suspecting that my
Ubuntu<BR>gcc 3.4 build is suffering from the problem described
at:<BR><BR> <A
href="http://bugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=293466">http://bugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=293466</A><BR><BR>So,
if people are running into strange crashes, and tracebacks in<BR>gcc show it
being deep in the glibc mt_allocator while destroying<BR>XalanDOMString's, I
would suggest defining the GLIBCXX_FORCE_NEW<BR>environment variable. I
results in a 20-30% speed reduction in<BR>the FDO core unit tests, so there is
a performance impact. But things<BR>run clean.<BR><BR>I *imagine* this
is fixed in newer versions of Debian/Ubuntu. I'm running<BR>one
generation behind (Ubuntu Breezy Badger).<BR><BR>God my head hurts.<BR><BR>PS.
Google on mt_alloc and GLIBCXX_FORCE_NEW is educational for those<BR>so
inclined. Mateusz - please read up on this so you can help me next
time<BR>I have this problem, and I've completely forgotten what I learned this
time.<BR><BR>:-)<BR><BR>Now enjoying my FDO Core UnitTest results:<BR><BR>OK
(102)<BR><BR><BR>Best
regards,<BR>--<BR>---------------------------------------+--------------------------------------<BR>I
set the clouds in motion - turn up | Frank Warmerdam,
warmerdam@pobox.com<BR>light and sound - activate the windows | <A
href="http://pobox.com/~warmerdam">http://pobox.com/~warmerdam</A><BR>and
watch the world go round - Rush | President OSGeo, <A
href="http://osgeo.org">http://osgeo.org</A><BR><BR>_______________________________________________<BR>fdo-internals
mailing list<BR>fdo-internals@lists.osgeo.org<BR><A
href="http://lists.osgeo.org/mailman/listinfo/fdo-internals">http://lists.osgeo.org/mailman/listinfo/fdo-internals</A><BR></FONT></P></BLOCKQUOTE>
</BODY>
</HTML>