[prev in list] [next in list] [prev in thread] [next in thread]
List: xalan-dev
Subject: xalan-c on linux gcc 3.3 - memory leak
From: "Tor Arne Gustad" <torag () stud ! aitel ! hist ! no>
Date: 2004-04-28 18:40:46
Message-ID: 001901c42d50$520d6660$2634269e () aitelstud ! aitel ! hist ! no
[Download RAW message or body]
Hello!
I have recently been working on a daemon that will eventually be used to =
validate and transform various XML data from one structure to another. =
The initial work was done on a debian-computer with gcc 2.95.4, and when =
using LeakTracer to check my code I finally got rid of all memory leaks. =
All was good.
The work is unfortunately to be continued on another computer, one =
running gcc 3.3, but after compiling and running it there I noticed it =
had started leaking memory again. I tracked down the problem and found =
it had to do with the xalan-c library. I am pretty sure this doesn't =
have to do with my code, since I did some testing with an empty program =
(no includes, no function calls, just "int main(...){ }" ) and found =
that if I simply linked it to "libxalan-c.so", it lost exactly 1920 =
bytes. This does not occur by linking "libxerces-c.so" and =
"libxalanMsg.so".
I have tried several approaches to the problem including recompiling =
xalan with other flags, but nothing has helped. Here are a list of =
relevant information/libraries:
- linux 2.4.20
- gcc 3.3
- libstdc++.so.5.0.4
- libm-2.3.2.so
- libc-2.3.2.so
- ld-2.3.2.so
- libpthread-0.10.so
- libxerces-c.so.25.0
Thanks in advance!
Tor Arne Gustad
[Attachment #3 (text/html)]
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.3790.118" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=Arial size=2>Hello!</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>I have recently been working on a daemon that will
eventually be used to validate and transform various XML data from one structure
to another. </FONT><FONT face=Arial size=2>The initial work was done on a
debian-computer with gcc 2.95.4, and when using LeakTracer to check my code I
finally got rid of all memory leaks. All was good.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>The work is unfortunately to be continued on
another computer, one running gcc 3.3, but after compiling and running it there
I noticed it had started leaking memory again. I tracked down the problem and
found it had to do with the xalan-c library. </FONT><FONT face=Arial size=2>I am
pretty sure this doesn't have to do with my code, since I did some testing with
an empty program (no includes, no function calls, just "int main(...){ }" ) and
found that if I simply linked it to "libxalan-c.so", it lost exactly 1920 bytes.
This does not occur by linking "libxerces-c.so" and
"libxalanMsg.so".</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>I have tried several approaches to the problem
including recompiling xalan with other flags, but nothing has helped. Here are a
list of relevant information/libraries:</FONT></DIV>
<DIV><FONT face=Arial size=2>- linux 2.4.20</FONT></DIV>
<DIV><FONT face=Arial size=2>- gcc 3.3</FONT></DIV>
<DIV><FONT face=Arial size=2>- libstdc++.so.5.0.4</FONT></DIV>
<DIV><FONT face=Arial size=2>- libm-2.3.2.so</FONT></DIV>
<DIV><FONT face=Arial size=2>- libc-2.3.2.so</FONT></DIV>
<DIV><FONT face=Arial size=2>- ld-2.3.2.so</FONT></DIV>
<DIV><FONT face=Arial size=2>- libpthread-0.10.so</FONT></DIV>
<DIV><FONT face=Arial size=2>- libxerces-c.so.25.0</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>Thanks in advance!</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>Tor Arne Gustad</FONT></DIV></BODY></HTML>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic