I need some advice on how to pursue a mystery memory leak. Here is the
story:
I have a memory leak in a Photon C++ app built using the (default) Dinkum
libs.
Code inspection couldn’t find anything, so I decided to try to use the
malloc_g library to track it down. But it seems that malloc_g it is
incompatible with Dinkum and requires the use of the GNU C/C++ libs. So I
recompiled everything using “-V gcc_ntox86_gpp -l malloc_g” to get the
malloc_g libs.
(Side note 1: Wow. I’d forgotten how much quicker this is to compile than
using Dinkum. Over 2x speed improvement to build our project).
(Side note 2: malloc_g/malloc.h tries to replace string.h but doesn’t
provide a prototype for strerror(). This is a bit of a PITA).
Now everything is built and I have all the tools I need to track down that
pesky memory leak.- but here’s the mystery: it’s gone away. No other code
changes and my exact same test case produces no leak.
Huh?
The only conclusion that I can draw is that there is a memory leak within
the Dinkum libs themselves - but this seems highly improbable,
asymptotically approaching impossible.
So…
- is it possible to use the malloc_g library with the Dinkum libs? Is there
some trick I am missing?
- has anyone else seen anything like this with Dinkum?
- any other ideas/suggestions?
Rob Rutherford
Ruzz Technology
I should add (in case it’s relevant) that the version we are using is the
“final beta” of 6.2 - we are still waiting to receive the release version
from our local distributor.
Rob Rutherford
“Robert Rutherford” <ruzz@NoSpamPlease.ruzz.com> wrote in message
news:afp0le$8k2$1@inn.qnx.com…
I need some advice on how to pursue a mystery memory leak. Here is the
story:
I have a memory leak in a Photon C++ app built using the (default) Dinkum
libs.
Code inspection couldn’t find anything, so I decided to try to use the
malloc_g library to track it down. But it seems that malloc_g it is
incompatible with Dinkum and requires the use of the GNU C/C++ libs. So I
recompiled everything using “-V gcc_ntox86_gpp -l malloc_g” to get the
malloc_g libs.
(Side note 1: Wow. I’d forgotten how much quicker this is to compile than
using Dinkum. Over 2x speed improvement to build our project).
(Side note 2: malloc_g/malloc.h tries to replace string.h but doesn’t
provide a prototype for strerror(). This is a bit of a PITA).
Now everything is built and I have all the tools I need to track down that
pesky memory leak.- but here’s the mystery: it’s gone away. No other code
changes and my exact same test case produces no leak.
Huh?
The only conclusion that I can draw is that there is a memory leak within
the Dinkum libs themselves - but this seems highly improbable,
asymptotically approaching impossible.
So…
- is it possible to use the malloc_g library with the Dinkum libs? Is
there
some trick I am missing?
- has anyone else seen anything like this with Dinkum?
- any other ideas/suggestions?
Rob Rutherford
Ruzz Technology
I recently tried to use again malloc_g library in 6.1 and it seems that
there is lot of problems of unknown symbols also (malloc_dump,
malloc_dump_unreferenced, mallopt(),…).
I think it’s not a 6.2 problem only.
cheers
Alain.
Robert Rutherford wrote:
I need some advice on how to pursue a mystery memory leak. Here is the
story:
I have a memory leak in a Photon C++ app built using the (default) Dinkum
libs.
Code inspection couldn’t find anything, so I decided to try to use the
malloc_g library to track it down. But it seems that malloc_g it is
incompatible with Dinkum and requires the use of the GNU C/C++ libs. So I
recompiled everything using “-V gcc_ntox86_gpp -l malloc_g” to get the
malloc_g libs.
(Side note 1: Wow. I’d forgotten how much quicker this is to compile than
using Dinkum. Over 2x speed improvement to build our project).
(Side note 2: malloc_g/malloc.h tries to replace string.h but doesn’t
provide a prototype for strerror(). This is a bit of a PITA).
Now everything is built and I have all the tools I need to track down that
pesky memory leak.- but here’s the mystery: it’s gone away. No other code
changes and my exact same test case produces no leak.
Huh?
The only conclusion that I can draw is that there is a memory leak within
the Dinkum libs themselves - but this seems highly improbable,
asymptotically approaching impossible.
So…
- is it possible to use the malloc_g library with the Dinkum libs? Is there
some trick I am missing?
- has anyone else seen anything like this with Dinkum?
- any other ideas/suggestions?
Rob Rutherford
Ruzz Technology
rather there is a leak in YOUR code.
it is typicall behaviour that programms run with one set of
libs/compiler/cpu and break on an other.
imho crossdevelopment is the best means of debugging there is.
Jörg
“Robert Rutherford” <ruzz@NoSpamPlease.ruzz.com> schrieb im Newsbeitrag
news:afp0le$8k2$1@inn.qnx.com…
I need some advice on how to pursue a mystery memory leak. Here is the
story:
I have a memory leak in a Photon C++ app built using the (default) Dinkum
libs.
Code inspection couldn’t find anything, so I decided to try to use the
malloc_g library to track it down. But it seems that malloc_g it is
incompatible with Dinkum and requires the use of the GNU C/C++ libs. So I
recompiled everything using “-V gcc_ntox86_gpp -l malloc_g” to get the
malloc_g libs.
(Side note 1: Wow. I’d forgotten how much quicker this is to compile than
using Dinkum. Over 2x speed improvement to build our project).
(Side note 2: malloc_g/malloc.h tries to replace string.h but doesn’t
provide a prototype for strerror(). This is a bit of a PITA).
Now everything is built and I have all the tools I need to track down that
pesky memory leak.- but here’s the mystery: it’s gone away. No other code
changes and my exact same test case produces no leak.
Huh?
The only conclusion that I can draw is that there is a memory leak within
the Dinkum libs themselves - but this seems highly improbable,
asymptotically approaching impossible.
So…
- is it possible to use the malloc_g library with the Dinkum libs? Is
there
some trick I am missing?
- has anyone else seen anything like this with Dinkum?
- any other ideas/suggestions?
Rob Rutherford
Ruzz Technology
This particular issue turned out to be caused by a flaw in the compiler used
to build libcpp. We are working to correct it for the upcoming patch.
“Joerg Scherer” <joerg.schererNOSPAM@gmx.de> wrote in message
news:aib9tb$hh$1@inn.qnx.com…
rather there is a leak in YOUR code.
it is typicall behaviour that programms run with one set of
libs/compiler/cpu and break on an other.
imho crossdevelopment is the best means of debugging there is.
Jörg
“Robert Rutherford” <> ruzz@NoSpamPlease.ruzz.com> > schrieb im Newsbeitrag
news:afp0le$8k2$> 1@inn.qnx.com> …
I need some advice on how to pursue a mystery memory leak. Here is the
story:
I have a memory leak in a Photon C++ app built using the (default)
Dinkum
libs.
Code inspection couldn’t find anything, so I decided to try to use the
malloc_g library to track it down. But it seems that malloc_g it is
incompatible with Dinkum and requires the use of the GNU C/C++ libs. So
I
recompiled everything using “-V gcc_ntox86_gpp -l malloc_g” to get the
malloc_g libs.
(Side note 1: Wow. I’d forgotten how much quicker this is to compile
than
using Dinkum. Over 2x speed improvement to build our project).
(Side note 2: malloc_g/malloc.h tries to replace string.h but doesn’t
provide a prototype for strerror(). This is a bit of a PITA).
Now everything is built and I have all the tools I need to track down
that
pesky memory leak.- but here’s the mystery: it’s gone away. No other
code
changes and my exact same test case produces no leak.
Huh?
The only conclusion that I can draw is that there is a memory leak
within
the Dinkum libs themselves - but this seems highly improbable,
asymptotically approaching impossible.
So…
- is it possible to use the malloc_g library with the Dinkum libs? Is
there
some trick I am missing?
- has anyone else seen anything like this with Dinkum?
- any other ideas/suggestions?
Rob Rutherford
Ruzz Technology
\
We’re rolling out a large C++ application on x86 6.1. It heavily uses STL
containers. We’ve had repeated crashes that we’ve not yet been able to
explain. Please explain the flaw and its implications.
If this flaw affects 6.1, is there a patch planned for 6.1 that would fix
it?
Thanks,
Marty Doane
Siemens Dematic
“Jeff Baker” <jbaker@qnx.com> wrote in message
news:aiecin$d4u$1@nntp.qnx.com…
This particular issue turned out to be caused by a flaw in the compiler
used
to build libcpp. We are working to correct it for the upcoming patch.
“Joerg Scherer” <> joerg.schererNOSPAM@gmx.de> > wrote in message
news:aib9tb$hh$> 1@inn.qnx.com> …
rather there is a leak in YOUR code.
it is typicall behaviour that programms run with one set of
libs/compiler/cpu and break on an other.
imho crossdevelopment is the best means of debugging there is.
Jörg
“Robert Rutherford” <> ruzz@NoSpamPlease.ruzz.com> > schrieb im Newsbeitrag
news:afp0le$8k2$> 1@inn.qnx.com> …
I need some advice on how to pursue a mystery memory leak. Here is the
story:
I have a memory leak in a Photon C++ app built using the (default)
Dinkum
libs.
Code inspection couldn’t find anything, so I decided to try to use the
malloc_g library to track it down. But it seems that malloc_g it is
incompatible with Dinkum and requires the use of the GNU C/C++ libs.
So
I
recompiled everything using “-V gcc_ntox86_gpp -l malloc_g” to get the
malloc_g libs.
(Side note 1: Wow. I’d forgotten how much quicker this is to compile
than
using Dinkum. Over 2x speed improvement to build our project).
(Side note 2: malloc_g/malloc.h tries to replace string.h but doesn’t
provide a prototype for strerror(). This is a bit of a PITA).
Now everything is built and I have all the tools I need to track down
that
pesky memory leak.- but here’s the mystery: it’s gone away. No other
code
changes and my exact same test case produces no leak.
Huh?
The only conclusion that I can draw is that there is a memory leak
within
the Dinkum libs themselves - but this seems highly improbable,
asymptotically approaching impossible.
So…
- is it possible to use the malloc_g library with the Dinkum libs? Is
there
some trick I am missing?
- has anyone else seen anything like this with Dinkum?
- any other ideas/suggestions?
Rob Rutherford
Ruzz Technology
\
Marty Doane <marty.doane@rapistan.com> wrote:
We’re rolling out a large C++ application on x86 6.1. It heavily uses STL
containers. We’ve had repeated crashes that we’ve not yet been able to
explain. Please explain the flaw and its implications.
If this flaw affects 6.1, is there a patch planned for 6.1 that would fix
it?
The flaw mentioned only affects the 6.2 release
The boolean size was changed so that it would match across all neutrino
platforms. In some cases (eg x86) this meant the sizeof(bool) changed
from 1 to 4 bytes.
\
cburgess@qnx.com
Try running Electric Fence on your application. You can get efence from
http://sourceforge.net/projects/openqnx/
“Marty Doane” <marty.doane@rapistan.com> wrote in message
news:aieii9$f2g$1@inn.qnx.com…
We’re rolling out a large C++ application on x86 6.1. It heavily uses STL
containers. We’ve had repeated crashes that we’ve not yet been able to
explain. Please explain the flaw and its implications.
If this flaw affects 6.1, is there a patch planned for 6.1 that would fix
it?
Thanks,
Marty Doane
Siemens Dematic
“Jeff Baker” <> jbaker@qnx.com> > wrote in message
news:aiecin$d4u$> 1@nntp.qnx.com> …
This particular issue turned out to be caused by a flaw in the compiler
used
to build libcpp. We are working to correct it for the upcoming patch.
“Joerg Scherer” <> joerg.schererNOSPAM@gmx.de> > wrote in message
news:aib9tb$hh$> 1@inn.qnx.com> …
rather there is a leak in YOUR code.
it is typicall behaviour that programms run with one set of
libs/compiler/cpu and break on an other.
imho crossdevelopment is the best means of debugging there is.
Jörg
“Robert Rutherford” <> ruzz@NoSpamPlease.ruzz.com> > schrieb im
Newsbeitrag
news:afp0le$8k2$> 1@inn.qnx.com> …
I need some advice on how to pursue a mystery memory leak. Here is
the
story:
I have a memory leak in a Photon C++ app built using the (default)
Dinkum
libs.
Code inspection couldn’t find anything, so I decided to try to use
the
malloc_g library to track it down. But it seems that malloc_g it is
incompatible with Dinkum and requires the use of the GNU C/C++ libs.
So
I
recompiled everything using “-V gcc_ntox86_gpp -l malloc_g” to get
the
malloc_g libs.
(Side note 1: Wow. I’d forgotten how much quicker this is to compile
than
using Dinkum. Over 2x speed improvement to build our project).
(Side note 2: malloc_g/malloc.h tries to replace string.h but
doesn’t
provide a prototype for strerror(). This is a bit of a PITA).
Now everything is built and I have all the tools I need to track
down
that
pesky memory leak.- but here’s the mystery: it’s gone away. No other
code
changes and my exact same test case produces no leak.
Huh?
The only conclusion that I can draw is that there is a memory leak
within
the Dinkum libs themselves - but this seems highly improbable,
asymptotically approaching impossible.
So…
- is it possible to use the malloc_g library with the Dinkum libs?
Is
there
some trick I am missing?
- has anyone else seen anything like this with Dinkum?
- any other ideas/suggestions?
Rob Rutherford
Ruzz Technology
\
Does this one have anything to do with the problems using ifstream and cin
together?
For instance this will cause segv in 6.2.0:
#include
#include
using namespace std;
void main( void )
{
ifstream inFile;
char in;
cin >> in; // this dumps core
cout << in << endl;
}
“Colin Burgess” <cburgess@qnx.com> wrote in message
news:aiom58$s8g$1@nntp.qnx.com…
Marty Doane <> marty.doane@rapistan.com> > wrote:
We’re rolling out a large C++ application on x86 6.1. It heavily uses
STL
containers. We’ve had repeated crashes that we’ve not yet been able to
explain. Please explain the flaw and its implications.
If this flaw affects 6.1, is there a patch planned for 6.1 that would
fix
it?
The flaw mentioned only affects the 6.2 release
The boolean size was changed so that it would match across all neutrino
platforms. In some cases (eg x86) this meant the sizeof(bool) changed
from 1 to 4 bytes.
\
cburgess@qnx.com
Yes, that’s exactly the problem.
Jens H Jorgensen <jhj@remove-nospam-videk.com> wrote:
Does this one have anything to do with the problems using ifstream and cin
together?
For instance this will cause segv in 6.2.0:
#include <iostream
#include <fstream
using namespace std;
void main( void )
{
ifstream inFile;
char in;
cin >> in; // this dumps core
cout << in << endl;
}
“Colin Burgess” <> cburgess@qnx.com> > wrote in message
news:aiom58$s8g$> 1@nntp.qnx.com> …
Marty Doane <> marty.doane@rapistan.com> > wrote:
We’re rolling out a large C++ application on x86 6.1. It heavily uses
STL
containers. We’ve had repeated crashes that we’ve not yet been able to
explain. Please explain the flaw and its implications.
If this flaw affects 6.1, is there a patch planned for 6.1 that would
fix
it?
The flaw mentioned only affects the 6.2 release
The boolean size was changed so that it would match across all neutrino
platforms. In some cases (eg x86) this meant the sizeof(bool) changed
from 1 to 4 bytes.
\
cburgess@qnx.com
–
cburgess@qnx.com
Is there any chance that a preliminary patch is going to come out addressing
this issue - as it is pretty annoying that we had to rewrite our STL
application to not use cin. I am not very comfortable either with the
current build of libcpp with the below mentioned problems.
–
Jens
“Colin Burgess” <cburgess@qnx.com> wrote in message
news:aiop19$1mf$1@nntp.qnx.com…
Yes, that’s exactly the problem.
Jens H Jorgensen <> jhj@remove-nospam-videk.com> > wrote:
Does this one have anything to do with the problems using ifstream and
cin
together?
For instance this will cause segv in 6.2.0:
#include <iostream
#include <fstream
using namespace std;
void main( void )
{
ifstream inFile;
char in;
cin >> in; // this dumps core
cout << in << endl;
}
“Colin Burgess” <> cburgess@qnx.com> > wrote in message
news:aiom58$s8g$> 1@nntp.qnx.com> …
Marty Doane <> marty.doane@rapistan.com> > wrote:
We’re rolling out a large C++ application on x86 6.1. It heavily uses
STL
containers. We’ve had repeated crashes that we’ve not yet been able
to
explain. Please explain the flaw and its implications.
If this flaw affects 6.1, is there a patch planned for 6.1 that would
fix
it?
The flaw mentioned only affects the 6.2 release
The boolean size was changed so that it would match across all neutrino
platforms. In some cases (eg x86) this meant the sizeof(bool) changed
from 1 to 4 bytes.
\
cburgess@qnx.com
Jens H Jorgensen <jhj@remove-nospam-videk.com> wrote:
Is there any chance that a preliminary patch is going to come out addressing
this issue - as it is pretty annoying that we had to rewrite our STL
application to not use cin. I am not very comfortable either with the
current build of libcpp with the below mentioned problems.
I believe that a fixed libc will be available as an experimental patch
soon.
–
Jens
“Colin Burgess” <> cburgess@qnx.com> > wrote in message
news:aiop19$1mf$> 1@nntp.qnx.com> …
Yes, that’s exactly the problem.
Jens H Jorgensen <> jhj@remove-nospam-videk.com> > wrote:
Does this one have anything to do with the problems using ifstream and
cin
together?
For instance this will cause segv in 6.2.0:
#include <iostream
#include <fstream
using namespace std;
void main( void )
{
ifstream inFile;
char in;
cin >> in; // this dumps core
cout << in << endl;
}
“Colin Burgess” <> cburgess@qnx.com> > wrote in message
news:aiom58$s8g$> 1@nntp.qnx.com> …
Marty Doane <> marty.doane@rapistan.com> > wrote:
We’re rolling out a large C++ application on x86 6.1. It heavily uses
STL
containers. We’ve had repeated crashes that we’ve not yet been able
to
explain. Please explain the flaw and its implications.
If this flaw affects 6.1, is there a patch planned for 6.1 that would
fix
it?
The flaw mentioned only affects the 6.2 release
The boolean size was changed so that it would match across all neutrino
platforms. In some cases (eg x86) this meant the sizeof(bool) changed
from 1 to 4 bytes.
\
cburgess@qnx.com
–
cburgess@qnx.com
Colin,
What would be the best way of “signing up” for this experimental patched
libc?
Thanks
Jens
“Colin Burgess” <cburgess@qnx.com> wrote in message
news:aip9p5$ea8$1@nntp.qnx.com…
Jens H Jorgensen <> jhj@remove-nospam-videk.com> > wrote:
Is there any chance that a preliminary patch is going to come out
addressing
this issue - as it is pretty annoying that we had to rewrite our STL
application to not use cin. I am not very comfortable either with the
current build of libcpp with the below mentioned problems.
I believe that a fixed libc will be available as an experimental patch
soon.
–
Jens
“Colin Burgess” <> cburgess@qnx.com> > wrote in message
news:aiop19$1mf$> 1@nntp.qnx.com> …
Yes, that’s exactly the problem.
Jens H Jorgensen <> jhj@remove-nospam-videk.com> > wrote:
Does this one have anything to do with the problems using ifstream
and
cin
together?
For instance this will cause segv in 6.2.0:
#include <iostream
#include <fstream
using namespace std;
void main( void )
{
ifstream inFile;
char in;
cin >> in; // this dumps core
cout << in << endl;
}
“Colin Burgess” <> cburgess@qnx.com> > wrote in message
news:aiom58$s8g$> 1@nntp.qnx.com> …
Marty Doane <> marty.doane@rapistan.com> > wrote:
We’re rolling out a large C++ application on x86 6.1. It heavily
uses
STL
containers. We’ve had repeated crashes that we’ve not yet been
able
to
explain. Please explain the flaw and its implications.
If this flaw affects 6.1, is there a patch planned for 6.1 that
would
fix
it?
The flaw mentioned only affects the 6.2 release
The boolean size was changed so that it would match across all
neutrino
platforms. In some cases (eg x86) this meant the sizeof(bool)
changed
from 1 to 4 bytes.
\
cburgess@qnx.com
I don’t know as yet…
Jens H Jorgensen <jhj@remove-nospam-videk.com> wrote:
Colin,
What would be the best way of “signing up” for this experimental patched
libc?
Thanks
Jens
“Colin Burgess” <> cburgess@qnx.com> > wrote in message
news:aip9p5$ea8$> 1@nntp.qnx.com> …
Jens H Jorgensen <> jhj@remove-nospam-videk.com> > wrote:
Is there any chance that a preliminary patch is going to come out
addressing
this issue - as it is pretty annoying that we had to rewrite our STL
application to not use cin. I am not very comfortable either with the
current build of libcpp with the below mentioned problems.
I believe that a fixed libc will be available as an experimental patch
soon.
–
Jens
“Colin Burgess” <> cburgess@qnx.com> > wrote in message
news:aiop19$1mf$> 1@nntp.qnx.com> …
Yes, that’s exactly the problem.
Jens H Jorgensen <> jhj@remove-nospam-videk.com> > wrote:
Does this one have anything to do with the problems using ifstream
and
cin
together?
For instance this will cause segv in 6.2.0:
#include <iostream
#include <fstream
using namespace std;
void main( void )
{
ifstream inFile;
char in;
cin >> in; // this dumps core
cout << in << endl;
}
“Colin Burgess” <> cburgess@qnx.com> > wrote in message
news:aiom58$s8g$> 1@nntp.qnx.com> …
Marty Doane <> marty.doane@rapistan.com> > wrote:
We’re rolling out a large C++ application on x86 6.1. It heavily
uses
STL
containers. We’ve had repeated crashes that we’ve not yet been
able
to
explain. Please explain the flaw and its implications.
If this flaw affects 6.1, is there a patch planned for 6.1 that
would
fix
it?
The flaw mentioned only affects the 6.2 release
The boolean size was changed so that it would match across all
neutrino
platforms. In some cases (eg x86) this meant the sizeof(bool)
changed
from 1 to 4 bytes.
\
cburgess@qnx.com
–
cburgess@qnx.com