ossim newbie

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

ossim newbie

Norman Goldstein
I am running on Fedora18, x86, 32 bit.
Downloaded ossim via svn on 17 July 2013.

I have built a good chunk of ossim, and have written a simple program
that instantiates an ossimWgs84Datum, and prints out its properties.  
Two problems

1. The printout is not correct.
2. The memory management is not clean

Here is the program

////////////////////////////////////// tossim.cpp
/////////////////////////////////////////////////////////////
#include <iostream>
#include "ossim/base/ossimWgs84Datum.h"

// When set to true, the Ellipsoid and EpsgDatum factoires
// are manually deleted.
// When set to false, ossim initialize is called, instead.
#define USE_UNIQUE 1

#if USE_UNIQUE
   #include "ossim/base/ossimEllipsoidFactory.h"
   #include "ossim/base/ossimEpsgDatumFactory.h"
   #include <memory>
#else
   #include "ossim/init/ossimInit.h"
#endif

using namespace std;

int main( int argc, char* argv[] )
{
#if USE_UNIQUE
   unique_ptr< ossimEllipsoidFactory >
     ellFac( ossimEllipsoidFactory::instance() );

   unique_ptr< ossimEpsgDatumFactory >
     epsgFac( ossimEpsgDatumFactory::instance() );
#else
   ossimInit::instance()->initialize( argc, argv );
#endif

   ossimWgs84Datum wgs84;

   cout << "param1= " << wgs84.param1() << endl;
   cout << "param2= " << wgs84.param2() << endl;
   cout << "param3= " << wgs84.param3() << endl;
   cout << "param4= " << wgs84.param4() << endl;
   cout << "param5= " << wgs84.param5() << endl;
   cout << "param6= " << wgs84.param6() << endl;
   cout << "param7= " << wgs84.param7() << endl;

   cout << "westLongitude= " << wgs84.westLongitude() << endl;
   cout << "eastLongitude= " << wgs84.eastLongitude() << endl;
   cout << "southLatitude= " << wgs84.southLatitude() << endl;
   cout << "northLatitude= " << wgs84.northLatitude() << endl;

   cout << "sigmaX= " << wgs84.sigmaX() << endl;
   cout << "sigmaY= " << wgs84.sigmaY() << endl;
   cout << "sigmaZ= " << wgs84.sigmaZ() << endl;

   cout << "code= " << wgs84.code() << endl;
   cout << "name= " << wgs84.name() << endl;
   cout << "epsgCode= " << wgs84.epsgCode() << endl;

   return 0;
}// main
/////////////////////////////////////////////////////////////////////////////////////////////////////////

For either value of USE_UNIQUE, the printout is

param1= 0
param2= 0
param3= 0
param4= 0
param5= 0
param6= 0
param7= 1
westLongitude= -1.5708
eastLongitude= 1.5708
southLatitude= -3.14159
northLatitude= 3.14159
sigmaX= 0
sigmaY= 0
sigmaZ= 0
code= WGE
name= World Geodetic System 1984
epsgCode= 6326

Errors with the printout are:
-- Ellipse semi-axes are not shown
-- Lats and Longs are interchanged.

When USE_UNIQUE is set to false, valgrind reports many dangling memory
errors.
When USE_UNIQUE is set to true, the memory is much better:

 > valgrind  --leak-check=full ./tossim
<<< Deleted prgram output >>>
==21644==
==21644== HEAP SUMMARY:
==21644==     in use at exit: 3,940 bytes in 92 blocks
==21644==   total heap usage: 2,094 allocs, 2,002 frees, 104,578 bytes
allocated
==21644==
==21644== LEAK SUMMARY:
==21644==    definitely lost: 0 bytes in 0 blocks
==21644==    indirectly lost: 0 bytes in 0 blocks
==21644==      possibly lost: 0 bytes in 0 blocks
==21644==    still reachable: 3,940 bytes in 92 blocks
==21644==         suppressed: 0 bytes in 0 blocks
==21644== Reachable blocks (those to which a pointer was found) are not
shown.
==21644== To see them, rerun with: --leak-check=full --show-reachable=yes
==21644==
==21644== For counts of detected and suppressed errors, rerun with: -v
==21644== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

But still not perfect.  Here is one of the valgrind errors from the command
 > valgrind  --leak-check=full  --show-reachable=yes ./tossim

==21686== 2,048 bytes in 1 blocks are still reachable in loss record 87
of 87
==21686==    at 0x4008AAD: operator new(unsigned int)
(vg_replace_malloc.c:292)
==21686==    by 0x4D4DDD3:
__gnu_cxx::new_allocator<ossimTrace*>::allocate(unsigned int, void
const*) (new_allocator.h:94)
==21686==    by 0x4D4DBC5: std::_Vector_base<ossimTrace*,
std::allocator<ossimTrace*> >::_M_allocate(unsigned int) (in
/home/norm18/systems/ossim/SVN/src/local/lib/libossim.so.1.8.16)
==21686==    by 0x4D4D6C8: std::vector<ossimTrace*,
std::allocator<ossimTrace*>
 >::_M_insert_aux(__gnu_cxx::__normal_iterator<ossimTrace**,
std::vector<ossimTrace*, std::allocator<ossimTrace*> > >, ossimTrace*
const&) (vector.tcc:343)
==21686==    by 0x4D4D1D6: std::vector<ossimTrace*,
std::allocator<ossimTrace*> >::push_back(ossimTrace* const&)
(stl_vector.h:893)
==21686==    by 0x4D4CC70: ossimTraceManager::addTrace(ossimTrace*)
(ossimTraceManager.cpp:57)
==21686==    by 0x4D1BBD3: ossimTrace::ossimTrace(ossimString const&)
(ossimTrace.cpp:33)
==21686==    by 0x5415126:
__static_initialization_and_destruction_0(int, int)
(ossimChipperUtil.cpp:66)
==21686==    by 0x5415212: _GLOBAL__sub_I_ossimChipperUtil.cpp
(ossimChipperUtil.cpp:3861)
==21686==    by 0x43552695: call_init.part.0 (dl-init.c:82)
==21686==    by 0x4355275A: _dl_init (dl-init.c:53)
==21686==    by 0x4354418E: ??? (in /usr/lib/ld-2.16.so)

I suppose if I manyally shut down the Trace manager, it might fix this
error, but I feel I am missing key steps in managing an ossim session.  
I looked around, but did not find a complete description of how to start
up and shut down an ossim application.  For example, where is the
close-down counter part to
ossimInit::instance()->initialize( argc, argv )  ?
The finalize() method is a no-op.

Many thanks!












------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
www.ossim.org
Ossim-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/ossim-developer

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: ossim newbie

Garrett Potts-2
Hello Norman:

> 1. The printout is not correct.

Thank you for the heads up.  This is now fixed and put into SVN.


> 2. The memory management is not clean
>
> Here is the program

A lot of these are going to be false positives for parts of the singletons rely on the memory getting re-pooled on termination.  For example, the ossimTrace are statically allocated in cpp files and added to the trace manager for setting flags.  The ossimTrace destructor when pooled will un register itself from the manager before fully pooled back to the memory heap.  If you want to test the ossimTrace destruction add a print statement to the destructor and run the ossim-foo application again.

A lot of the valgrinds are probably going to give what it thinks are leaks in the singletons.  We just need to go through the report and weed out valid and invalid leak detections.


Thank you and if you have a full valgrind log you can send that on.

Take care

Garrett


------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
www.ossim.org
Ossim-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/ossim-developer
Reply | Threaded
Open this post in threaded view
|

Re: ossim newbie

Norman Goldstein
On 07/22/2013 05:10 AM, Garrett Potts wrote:
2. The memory management is not clean

A lot of these are going to be false positives for parts of the singletons rely on the memory getting re-pooled on termination.  For example, the ossimTrace are statically allocated in cpp files and added to the trace manager for setting flags.  The ossimTrace destructor when pooled will un register itself from the manager before fully pooled back to the memory heap.  If you want to test the ossimTrace destruction add a print statement to the destructor and run the ossim-foo application again.
I added an explicit destructor to ossimTraceManager.cpp

ossimTraceManager::~ossimTraceManager()
{
  std::cout << "In ossimTraceManager::~ossimTraceManager()"
        << std::endl;
}

and the declaration in ossimTraceManager.h.   But as you can see from
the output, below, the destructor message is not printed to the screen.
I rebuilt ossim by
make clean
make
make install



A lot of the valgrinds are probably going to give what it thinks are leaks in the singletons.  We just need to go through the report and weed out valid and invalid leak detections.


Thank you and if you have a full valgrind log you can send that on.



Thanks, Garrett.  I think it is important to have a clean valgrind report,
perhaps after adding suppressions that we are positive should be
suppressed.

At the bottom of main (see below, please), are two "delete" lines that I
am not comfortable with, even though they greatly improve the valgrind
report.  They may be having side effects / incompatible with ossim code.

-- Attached is the valgrind output of the command
      valgrind --leak-check=full --show-reachable=yes --fullpath-after= ./tossim
   Without the "show-reachable" flag, no messages are printed, only the same
   leak summary at the bottom.

 -- When using the ossim initialize, I get a memory error, which is why
     I have that code in a compile guard.

-- Any info on compatibility of OSSIM with C++11?

-- The output still seems to be wrong:
       Should be radians, according to ossimThreeParamsDatum.h

//////////////////////// Output /////////////////////////////////////////
ossimWgs84Datum:
param1(dX)= 0
param2(dY)= 0
param3(dZ)= 0
param4(N/A)= 0
param5(N/A)= 0
param6(N/A)= 0
param7(N/A)= 1
westLongitude= -180
eastLongitude= 180
southLatitude= -90
northLatitude= 90
sigmaX= 0
sigmaY= 0
sigmaZ= 0
code= WGE
name= World Geodetic System 1984
epsgCode= 6326

//////////////////////////// Source Code (updated) ///////////////////////
#include <iostream>
#include "ossim/base/ossimWgs84Datum.h"

// When set to true, ossim initialize is used
#define USE_INIT 0

#include "ossim/base/ossimEllipsoidFactory.h"
#include "ossim/base/ossimEpsgDatumFactory.h"

#if USE_INIT
  #include "ossim/init/ossimInit.h"
#endif

using namespace std;

int main( int argc, char* argv[] )
{
#if USE_INIT
  ossimInit::instance()->initialize( argc, argv );
#endif

  ossimWgs84Datum wgs84;

  cout << "ossimWgs84Datum:" << endl;
  cout << "param1(dX)= " << wgs84.param1() << endl;
  cout << "param2(dY)= " << wgs84.param2() << endl;
  cout << "param3(dZ)= " << wgs84.param3() << endl;
  cout << "param4(N/A)= " << wgs84.param4() << endl;
  cout << "param5(N/A)= " << wgs84.param5() << endl;
  cout << "param6(N/A)= " << wgs84.param6() << endl;
  cout << "param7(N/A)= " << wgs84.param7() << endl;

  cout << "westLongitude= " << wgs84.westLongitude() << endl;
  cout << "eastLongitude= " << wgs84.eastLongitude() << endl;
  cout << "southLatitude= " << wgs84.southLatitude() << endl;
  cout << "northLatitude= " << wgs84.northLatitude() << endl;
 
  cout << "sigmaX= " << wgs84.sigmaX() << endl;
  cout << "sigmaY= " << wgs84.sigmaY() << endl;
  cout << "sigmaZ= " << wgs84.sigmaZ() << endl;

  cout << "code= " << wgs84.code() << endl;
  cout << "name= " << wgs84.name() << endl;
  cout << "epsgCode= " << wgs84.epsgCode() << endl;

  delete ossimEllipsoidFactory::instance();
  delete ossimEpsgDatumFactory::instance();

  return 0;
}// main





------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
www.ossim.org
Ossim-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/ossim-developer

tossim.vgd (104K) Download Attachment
smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: ossim newbie

Garrett Potts-2
Hello Norman:

Thank you for the valgrind.  

The destructor I was mentioning was in ossimTrace::~ossimTrace and not the ossimTraceManager.


Will peep at the singletons as we go.  They were always meant to be pooled when the program terminated.

I'll go through the valgrind this week and see if anything sticks and look at your suggestions.


Take care and thank you

Garrett

On Jul 22, 2013, at 4:18 PM, Norman Goldstein <[hidden email]> wrote:

> On 07/22/2013 05:10 AM, Garrett Potts wrote:
>> 2. The memory management is not clean
>>
>> A lot of these are going to be false positives for parts of the singletons rely on the memory getting re-pooled on termination.  For example, the ossimTrace are statically allocated in cpp files and added to the trace manager for setting flags.  The ossimTrace destructor when pooled will un register itself from the manager before fully pooled back to the memory heap.  If you want to test the ossimTrace destruction add a print statement to the destructor and run the ossim-foo application again.
> I added an explicit destructor to ossimTraceManager.cpp
>
> ossimTraceManager::~ossimTraceManager()
> {
>   std::cout << "In ossimTraceManager::~ossimTraceManager()"
>         << std::endl;
> }
>
> and the declaration in ossimTraceManager.h.   But as you can see from
> the output, below, the destructor message is not printed to the screen.
> I rebuilt ossim by
> make clean
> make
> make install
>
>>
>>
>> A lot of the valgrinds are probably going to give what it thinks are leaks in the singletons.  We just need to go through the report and weed out valid and invalid leak detections.
>>
>>
>> Thank you and if you have a full valgrind log you can send that on.
>>
>>
>
> Thanks, Garrett.  I think it is important to have a clean valgrind report,
> perhaps after adding suppressions that we are positive should be
> suppressed.
>
> At the bottom of main (see below, please), are two "delete" lines that I
> am not comfortable with, even though they greatly improve the valgrind
> report.  They may be having side effects / incompatible with ossim code.
>
> -- Attached is the valgrind output of the command
>       valgrind --leak-check=full --show-reachable=yes --fullpath-after= ./tossim
>    Without the "show-reachable" flag, no messages are printed, only the same
>    leak summary at the bottom.
>
>  -- When using the ossim initialize, I get a memory error, which is why
>      I have that code in a compile guard.
>
> -- Any info on compatibility of OSSIM with C++11?
>
> -- The output still seems to be wrong:
>        Should be radians, according to ossimThreeParamsDatum.h
>
> //////////////////////// Output /////////////////////////////////////////
> ossimWgs84Datum:
> param1(dX)= 0
> param2(dY)= 0
> param3(dZ)= 0
> param4(N/A)= 0
> param5(N/A)= 0
> param6(N/A)= 0
> param7(N/A)= 1
> westLongitude= -180
> eastLongitude= 180
> southLatitude= -90
> northLatitude= 90
> sigmaX= 0
> sigmaY= 0
> sigmaZ= 0
> code= WGE
> name= World Geodetic System 1984
> epsgCode= 6326
>
> //////////////////////////// Source Code (updated) ///////////////////////
> #include <iostream>
> #include "ossim/base/ossimWgs84Datum.h"
>
> // When set to true, ossim initialize is used
> #define USE_INIT 0
>
> #include "ossim/base/ossimEllipsoidFactory.h"
> #include "ossim/base/ossimEpsgDatumFactory.h"
>
> #if USE_INIT
>   #include "ossim/init/ossimInit.h"
> #endif
>
> using namespace std;
>
> int main( int argc, char* argv[] )
> {
> #if USE_INIT
>   ossimInit::instance()->initialize( argc, argv );
> #endif
>
>   ossimWgs84Datum wgs84;
>
>   cout << "ossimWgs84Datum:" << endl;
>   cout << "param1(dX)= " << wgs84.param1() << endl;
>   cout << "param2(dY)= " << wgs84.param2() << endl;
>   cout << "param3(dZ)= " << wgs84.param3() << endl;
>   cout << "param4(N/A)= " << wgs84.param4() << endl;
>   cout << "param5(N/A)= " << wgs84.param5() << endl;
>   cout << "param6(N/A)= " << wgs84.param6() << endl;
>   cout << "param7(N/A)= " << wgs84.param7() << endl;
>
>   cout << "westLongitude= " << wgs84.westLongitude() << endl;
>   cout << "eastLongitude= " << wgs84.eastLongitude() << endl;
>   cout << "southLatitude= " << wgs84.southLatitude() << endl;
>   cout << "northLatitude= " << wgs84.northLatitude() << endl;
>  
>   cout << "sigmaX= " << wgs84.sigmaX() << endl;
>   cout << "sigmaY= " << wgs84.sigmaY() << endl;
>   cout << "sigmaZ= " << wgs84.sigmaZ() << endl;
>
>   cout << "code= " << wgs84.code() << endl;
>   cout << "name= " << wgs84.name() << endl;
>   cout << "epsgCode= " << wgs84.epsgCode() << endl;
>
>   delete ossimEllipsoidFactory::instance();
>   delete ossimEpsgDatumFactory::instance();
>
>   return 0;
> }// main
>
>
>
>
> <tossim.vgd>------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk_______________________________________________
> www.ossim.org
> Ossim-developer mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/ossim-developer


------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
www.ossim.org
Ossim-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/ossim-developer
Reply | Threaded
Open this post in threaded view
|

Re: ossim newbie

David Burken
Hi Norman,

I have a mod to ossimTraceManager and ossimTrace that will be cleaner I
think.  I'll test today on different platforms and commit if good.

Dave

On 07/22/2013 09:44 PM, Garrett Potts wrote:

> Hello Norman:
>
> Thank you for the valgrind.
>
> The destructor I was mentioning was in ossimTrace::~ossimTrace and not the ossimTraceManager.
>
>
> Will peep at the singletons as we go.  They were always meant to be pooled when the program terminated.
>
> I'll go through the valgrind this week and see if anything sticks and look at your suggestions.
>
>
> Take care and thank you
>
> Garrett
>
> On Jul 22, 2013, at 4:18 PM, Norman Goldstein <[hidden email]> wrote:
>
>> On 07/22/2013 05:10 AM, Garrett Potts wrote:
>>> 2. The memory management is not clean
>>>
>>> A lot of these are going to be false positives for parts of the singletons rely on the memory getting re-pooled on termination.  For example, the ossimTrace are statically allocated in cpp files and added to the trace manager for setting flags.  The ossimTrace destructor when pooled will un register itself from the manager before fully pooled back to the memory heap.  If you want to test the ossimTrace destruction add a print statement to the destructor and run the ossim-foo application again.
>> I added an explicit destructor to ossimTraceManager.cpp
>>
>> ossimTraceManager::~ossimTraceManager()
>> {
>>    std::cout << "In ossimTraceManager::~ossimTraceManager()"
>>          << std::endl;
>> }
>>
>> and the declaration in ossimTraceManager.h.   But as you can see from
>> the output, below, the destructor message is not printed to the screen.
>> I rebuilt ossim by
>> make clean
>> make
>> make install
>>
>>>
>>> A lot of the valgrinds are probably going to give what it thinks are leaks in the singletons.  We just need to go through the report and weed out valid and invalid leak detections.
>>>
>>>
>>> Thank you and if you have a full valgrind log you can send that on.
>>>
>>>
>> Thanks, Garrett.  I think it is important to have a clean valgrind report,
>> perhaps after adding suppressions that we are positive should be
>> suppressed.
>>
>> At the bottom of main (see below, please), are two "delete" lines that I
>> am not comfortable with, even though they greatly improve the valgrind
>> report.  They may be having side effects / incompatible with ossim code.
>>
>> -- Attached is the valgrind output of the command
>>        valgrind --leak-check=full --show-reachable=yes --fullpath-after= ./tossim
>>     Without the "show-reachable" flag, no messages are printed, only the same
>>     leak summary at the bottom.
>>
>>   -- When using the ossim initialize, I get a memory error, which is why
>>       I have that code in a compile guard.
>>
>> -- Any info on compatibility of OSSIM with C++11?
>>
>> -- The output still seems to be wrong:
>>         Should be radians, according to ossimThreeParamsDatum.h
>>
>> //////////////////////// Output /////////////////////////////////////////
>> ossimWgs84Datum:
>> param1(dX)= 0
>> param2(dY)= 0
>> param3(dZ)= 0
>> param4(N/A)= 0
>> param5(N/A)= 0
>> param6(N/A)= 0
>> param7(N/A)= 1
>> westLongitude= -180
>> eastLongitude= 180
>> southLatitude= -90
>> northLatitude= 90
>> sigmaX= 0
>> sigmaY= 0
>> sigmaZ= 0
>> code= WGE
>> name= World Geodetic System 1984
>> epsgCode= 6326
>>
>> //////////////////////////// Source Code (updated) ///////////////////////
>> #include <iostream>
>> #include "ossim/base/ossimWgs84Datum.h"
>>
>> // When set to true, ossim initialize is used
>> #define USE_INIT 0
>>
>> #include "ossim/base/ossimEllipsoidFactory.h"
>> #include "ossim/base/ossimEpsgDatumFactory.h"
>>
>> #if USE_INIT
>>    #include "ossim/init/ossimInit.h"
>> #endif
>>
>> using namespace std;
>>
>> int main( int argc, char* argv[] )
>> {
>> #if USE_INIT
>>    ossimInit::instance()->initialize( argc, argv );
>> #endif
>>
>>    ossimWgs84Datum wgs84;
>>
>>    cout << "ossimWgs84Datum:" << endl;
>>    cout << "param1(dX)= " << wgs84.param1() << endl;
>>    cout << "param2(dY)= " << wgs84.param2() << endl;
>>    cout << "param3(dZ)= " << wgs84.param3() << endl;
>>    cout << "param4(N/A)= " << wgs84.param4() << endl;
>>    cout << "param5(N/A)= " << wgs84.param5() << endl;
>>    cout << "param6(N/A)= " << wgs84.param6() << endl;
>>    cout << "param7(N/A)= " << wgs84.param7() << endl;
>>
>>    cout << "westLongitude= " << wgs84.westLongitude() << endl;
>>    cout << "eastLongitude= " << wgs84.eastLongitude() << endl;
>>    cout << "southLatitude= " << wgs84.southLatitude() << endl;
>>    cout << "northLatitude= " << wgs84.northLatitude() << endl;
>>    
>>    cout << "sigmaX= " << wgs84.sigmaX() << endl;
>>    cout << "sigmaY= " << wgs84.sigmaY() << endl;
>>    cout << "sigmaZ= " << wgs84.sigmaZ() << endl;
>>
>>    cout << "code= " << wgs84.code() << endl;
>>    cout << "name= " << wgs84.name() << endl;
>>    cout << "epsgCode= " << wgs84.epsgCode() << endl;
>>
>>    delete ossimEllipsoidFactory::instance();
>>    delete ossimEpsgDatumFactory::instance();
>>
>>    return 0;
>> }// main
>>
>>
>>
>>
>> <tossim.vgd>------------------------------------------------------------------------------
>> See everything from the browser to the database with AppDynamics
>> Get end-to-end visibility with application monitoring from AppDynamics
>> Isolate bottlenecks and diagnose root cause in seconds.
>> Start your free trial of AppDynamics Pro today!
>> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk_______________________________________________
>> www.ossim.org
>> Ossim-developer mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/ossim-developer
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> www.ossim.org
> Ossim-developer mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/ossim-developer
>


------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
www.ossim.org
Ossim-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/ossim-developer
Reply | Threaded
Open this post in threaded view
|

Re: ossim newbie

Garrett Potts-2
In reply to this post by Norman Goldstein
Hello Norman:

I looked at the RTTI stuff and I refactored the array to use std::vector and name to use std::string.  Could you update and see if any of the RTTI items go away.  The RTTItypeinfo constructor and destructors are being called.  Tried a refactor of the arrays to see if this is throwing valgrind off.


Take care

Garrett

On Jul 22, 2013, at 4:18 PM, Norman Goldstein <[hidden email]> wrote:

> On 07/22/2013 05:10 AM, Garrett Potts wrote:
>> 2. The memory management is not clean
>>
>> A lot of these are going to be false positives for parts of the singletons rely on the memory getting re-pooled on termination.  For example, the ossimTrace are statically allocated in cpp files and added to the trace manager for setting flags.  The ossimTrace destructor when pooled will un register itself from the manager before fully pooled back to the memory heap.  If you want to test the ossimTrace destruction add a print statement to the destructor and run the ossim-foo application again.
> I added an explicit destructor to ossimTraceManager.cpp
>
> ossimTraceManager::~ossimTraceManager()
> {
>   std::cout << "In ossimTraceManager::~ossimTraceManager()"
>         << std::endl;
> }
>
> and the declaration in ossimTraceManager.h.   But as you can see from
> the output, below, the destructor message is not printed to the screen.
> I rebuilt ossim by
> make clean
> make
> make install
>
>>
>>
>> A lot of the valgrinds are probably going to give what it thinks are leaks in the singletons.  We just need to go through the report and weed out valid and invalid leak detections.
>>
>>
>> Thank you and if you have a full valgrind log you can send that on.
>>
>>
>
> Thanks, Garrett.  I think it is important to have a clean valgrind report,
> perhaps after adding suppressions that we are positive should be
> suppressed.
>
> At the bottom of main (see below, please), are two "delete" lines that I
> am not comfortable with, even though they greatly improve the valgrind
> report.  They may be having side effects / incompatible with ossim code.
>
> -- Attached is the valgrind output of the command
>       valgrind --leak-check=full --show-reachable=yes --fullpath-after= ./tossim
>    Without the "show-reachable" flag, no messages are printed, only the same
>    leak summary at the bottom.
>
>  -- When using the ossim initialize, I get a memory error, which is why
>      I have that code in a compile guard.
>
> -- Any info on compatibility of OSSIM with C++11?
>
> -- The output still seems to be wrong:
>        Should be radians, according to ossimThreeParamsDatum.h
>
> //////////////////////// Output /////////////////////////////////////////
> ossimWgs84Datum:
> param1(dX)= 0
> param2(dY)= 0
> param3(dZ)= 0
> param4(N/A)= 0
> param5(N/A)= 0
> param6(N/A)= 0
> param7(N/A)= 1
> westLongitude= -180
> eastLongitude= 180
> southLatitude= -90
> northLatitude= 90
> sigmaX= 0
> sigmaY= 0
> sigmaZ= 0
> code= WGE
> name= World Geodetic System 1984
> epsgCode= 6326
>
> //////////////////////////// Source Code (updated) ///////////////////////
> #include <iostream>
> #include "ossim/base/ossimWgs84Datum.h"
>
> // When set to true, ossim initialize is used
> #define USE_INIT 0
>
> #include "ossim/base/ossimEllipsoidFactory.h"
> #include "ossim/base/ossimEpsgDatumFactory.h"
>
> #if USE_INIT
>   #include "ossim/init/ossimInit.h"
> #endif
>
> using namespace std;
>
> int main( int argc, char* argv[] )
> {
> #if USE_INIT
>   ossimInit::instance()->initialize( argc, argv );
> #endif
>
>   ossimWgs84Datum wgs84;
>
>   cout << "ossimWgs84Datum:" << endl;
>   cout << "param1(dX)= " << wgs84.param1() << endl;
>   cout << "param2(dY)= " << wgs84.param2() << endl;
>   cout << "param3(dZ)= " << wgs84.param3() << endl;
>   cout << "param4(N/A)= " << wgs84.param4() << endl;
>   cout << "param5(N/A)= " << wgs84.param5() << endl;
>   cout << "param6(N/A)= " << wgs84.param6() << endl;
>   cout << "param7(N/A)= " << wgs84.param7() << endl;
>
>   cout << "westLongitude= " << wgs84.westLongitude() << endl;
>   cout << "eastLongitude= " << wgs84.eastLongitude() << endl;
>   cout << "southLatitude= " << wgs84.southLatitude() << endl;
>   cout << "northLatitude= " << wgs84.northLatitude() << endl;
>  
>   cout << "sigmaX= " << wgs84.sigmaX() << endl;
>   cout << "sigmaY= " << wgs84.sigmaY() << endl;
>   cout << "sigmaZ= " << wgs84.sigmaZ() << endl;
>
>   cout << "code= " << wgs84.code() << endl;
>   cout << "name= " << wgs84.name() << endl;
>   cout << "epsgCode= " << wgs84.epsgCode() << endl;
>
>   delete ossimEllipsoidFactory::instance();
>   delete ossimEpsgDatumFactory::instance();
>
>   return 0;
> }// main
>
>
>
>
> <tossim.vgd>------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk_______________________________________________
> www.ossim.org
> Ossim-developer mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/ossim-developer


------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
www.ossim.org
Ossim-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/ossim-developer
Reply | Threaded
Open this post in threaded view
|

Re: ossim newbie

Norman Goldstein
I removed, downloaded and rebuilt. Attached is the new valgrind log.  
Same source code as below.  The valgrind command is

valgrind --leak-check=full --fullpath-after= ./tossim

The leak summary is

==17023== LEAK SUMMARY:
==17023==    definitely lost: 784 bytes in 52 blocks
==17023==    indirectly lost: 0 bytes in 0 blocks
==17023==      possibly lost: 0 bytes in 0 blocks
==17023==    still reachable: 2,064 bytes in 2 blocks
==17023==         suppressed: 0 bytes in 0 blocks

Previously, there were no "definately lost", only "still reachable".  
For this log, I did not give the "--show-reachable=yes" to valgrind.  
(The path to redemption has its twists and bumps :-) ).

If you can think of further ways I can help, in addition running
valgrind, please let me know.  What system are you building on?

Thank you,
Norm



On 07/24/2013 04:51 AM, Garrett Potts wrote:

> Hello Norman:
>
> I looked at the RTTI stuff and I refactored the array to use std::vector and name to use std::string.  Could you update and see if any of the RTTI items go away.  The RTTItypeinfo constructor and destructors are being called.  Tried a refactor of the arrays to see if this is throwing valgrind off.
>
>
> Take care
>
> Garrett
>
> On Jul 22, 2013, at 4:18 PM, Norman Goldstein <[hidden email]> wrote:
>
>> On 07/22/2013 05:10 AM, Garrett Potts wrote:
>>> 2. The memory management is not clean
>>>
>>> A lot of these are going to be false positives for parts of the singletons rely on the memory getting re-pooled on termination.  For example, the ossimTrace are statically allocated in cpp files and added to the trace manager for setting flags.  The ossimTrace destructor when pooled will un register itself from the manager before fully pooled back to the memory heap.  If you want to test the ossimTrace destruction add a print statement to the destructor and run the ossim-foo application again.
>> I added an explicit destructor to ossimTraceManager.cpp
>>
>> ossimTraceManager::~ossimTraceManager()
>> {
>>    std::cout << "In ossimTraceManager::~ossimTraceManager()"
>>          << std::endl;
>> }
>>
>> and the declaration in ossimTraceManager.h.   But as you can see from
>> the output, below, the destructor message is not printed to the screen.
>> I rebuilt ossim by
>> make clean
>> make
>> make install
>>
>>>
>>> A lot of the valgrinds are probably going to give what it thinks are leaks in the singletons.  We just need to go through the report and weed out valid and invalid leak detections.
>>>
>>>
>>> Thank you and if you have a full valgrind log you can send that on.
>>>
>>>
>> Thanks, Garrett.  I think it is important to have a clean valgrind report,
>> perhaps after adding suppressions that we are positive should be
>> suppressed.
>>
>> At the bottom of main (see below, please), are two "delete" lines that I
>> am not comfortable with, even though they greatly improve the valgrind
>> report.  They may be having side effects / incompatible with ossim code.
>>
>> -- Attached is the valgrind output of the command
>>        valgrind --leak-check=full --show-reachable=yes --fullpath-after= ./tossim
>>     Without the "show-reachable" flag, no messages are printed, only the same
>>     leak summary at the bottom.
>>
>>   -- When using the ossim initialize, I get a memory error, which is why
>>       I have that code in a compile guard.
>>
>> -- Any info on compatibility of OSSIM with C++11?
>>
>> -- The output still seems to be wrong:
>>         Should be radians, according to ossimThreeParamsDatum.h
>>
>> //////////////////////// Output /////////////////////////////////////////
>> ossimWgs84Datum:
>> param1(dX)= 0
>> param2(dY)= 0
>> param3(dZ)= 0
>> param4(N/A)= 0
>> param5(N/A)= 0
>> param6(N/A)= 0
>> param7(N/A)= 1
>> westLongitude= -180
>> eastLongitude= 180
>> southLatitude= -90
>> northLatitude= 90
>> sigmaX= 0
>> sigmaY= 0
>> sigmaZ= 0
>> code= WGE
>> name= World Geodetic System 1984
>> epsgCode= 6326
>>
>> //////////////////////////// Source Code (updated) ///////////////////////
>> #include <iostream>
>> #include "ossim/base/ossimWgs84Datum.h"
>>
>> // When set to true, ossim initialize is used
>> #define USE_INIT 0
>>
>> #include "ossim/base/ossimEllipsoidFactory.h"
>> #include "ossim/base/ossimEpsgDatumFactory.h"
>>
>> #if USE_INIT
>>    #include "ossim/init/ossimInit.h"
>> #endif
>>
>> using namespace std;
>>
>> int main( int argc, char* argv[] )
>> {
>> #if USE_INIT
>>    ossimInit::instance()->initialize( argc, argv );
>> #endif
>>
>>    ossimWgs84Datum wgs84;
>>
>>    cout << "ossimWgs84Datum:" << endl;
>>    cout << "param1(dX)= " << wgs84.param1() << endl;
>>    cout << "param2(dY)= " << wgs84.param2() << endl;
>>    cout << "param3(dZ)= " << wgs84.param3() << endl;
>>    cout << "param4(N/A)= " << wgs84.param4() << endl;
>>    cout << "param5(N/A)= " << wgs84.param5() << endl;
>>    cout << "param6(N/A)= " << wgs84.param6() << endl;
>>    cout << "param7(N/A)= " << wgs84.param7() << endl;
>>
>>    cout << "westLongitude= " << wgs84.westLongitude() << endl;
>>    cout << "eastLongitude= " << wgs84.eastLongitude() << endl;
>>    cout << "southLatitude= " << wgs84.southLatitude() << endl;
>>    cout << "northLatitude= " << wgs84.northLatitude() << endl;
>>    
>>    cout << "sigmaX= " << wgs84.sigmaX() << endl;
>>    cout << "sigmaY= " << wgs84.sigmaY() << endl;
>>    cout << "sigmaZ= " << wgs84.sigmaZ() << endl;
>>
>>    cout << "code= " << wgs84.code() << endl;
>>    cout << "name= " << wgs84.name() << endl;
>>    cout << "epsgCode= " << wgs84.epsgCode() << endl;
>>
>>    delete ossimEllipsoidFactory::instance();
>>    delete ossimEpsgDatumFactory::instance();
>>
>>    return 0;
>> }// main
>>
>>
>>
>>
>> <tossim.vgd>------------------------------------------------------------------------------
>> See everything from the browser to the database with AppDynamics
>> Get end-to-end visibility with application monitoring from AppDynamics
>> Isolate bottlenecks and diagnose root cause in seconds.
>> Start your free trial of AppDynamics Pro today!
>> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk_______________________________________________
>> www.ossim.org
>> Ossim-developer mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/ossim-developer
>

------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
www.ossim.org
Ossim-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/ossim-developer

tossim.vgd (112K) Download Attachment
smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: ossim newbie

David Burken
Hey thanks Norman,

So we just introduced a "definitely lost"?

I was doing a valgrind run as we speak.  We build on a variety of platforms, mac osx, linux's, Fedora, RH EN, CentOS, windoze...

Dave

On 07/24/2013 12:15 PM, Norman Goldstein wrote:
I removed, downloaded and rebuilt. Attached is the new valgrind log.  Same source code as below.  The valgrind command is

valgrind --leak-check=full --fullpath-after= ./tossim

The leak summary is

==17023== LEAK SUMMARY:
==17023==    definitely lost: 784 bytes in 52 blocks
==17023==    indirectly lost: 0 bytes in 0 blocks
==17023==      possibly lost: 0 bytes in 0 blocks
==17023==    still reachable: 2,064 bytes in 2 blocks
==17023==         suppressed: 0 bytes in 0 blocks

Previously, there were no "definately lost", only "still reachable".  For this log, I did not give the "--show-reachable=yes" to valgrind.  (The path to redemption has its twists and bumps :-) ).

If you can think of further ways I can help, in addition running valgrind, please let me know.  What system are you building on?

Thank you,
Norm



On 07/24/2013 04:51 AM, Garrett Potts wrote:
Hello Norman:

I looked at the RTTI stuff and I refactored the array to use std::vector and name to use std::string.  Could you update and see if any of the RTTI items go away.  The RTTItypeinfo constructor and destructors are being called.  Tried a refactor of the arrays to see if this is throwing valgrind off.


Take care

Garrett

On Jul 22, 2013, at 4:18 PM, Norman Goldstein [hidden email] wrote:

On 07/22/2013 05:10 AM, Garrett Potts wrote:
2. The memory management is not clean

A lot of these are going to be false positives for parts of the singletons rely on the memory getting re-pooled on termination.  For example, the ossimTrace are statically allocated in cpp files and added to the trace manager for setting flags.  The ossimTrace destructor when pooled will un register itself from the manager before fully pooled back to the memory heap.  If you want to test the ossimTrace destruction add a print statement to the destructor and run the ossim-foo application again.
I added an explicit destructor to ossimTraceManager.cpp

ossimTraceManager::~ossimTraceManager()
{
   std::cout << "In ossimTraceManager::~ossimTraceManager()"
         << std::endl;
}

and the declaration in ossimTraceManager.h.   But as you can see from
the output, below, the destructor message is not printed to the screen.
I rebuilt ossim by
make clean
make
make install


A lot of the valgrinds are probably going to give what it thinks are leaks in the singletons.  We just need to go through the report and weed out valid and invalid leak detections.


Thank you and if you have a full valgrind log you can send that on.


Thanks, Garrett.  I think it is important to have a clean valgrind report,
perhaps after adding suppressions that we are positive should be
suppressed.

At the bottom of main (see below, please), are two "delete" lines that I
am not comfortable with, even though they greatly improve the valgrind
report.  They may be having side effects / incompatible with ossim code.

-- Attached is the valgrind output of the command
       valgrind --leak-check=full --show-reachable=yes --fullpath-after= ./tossim
    Without the "show-reachable" flag, no messages are printed, only the same
    leak summary at the bottom.

  -- When using the ossim initialize, I get a memory error, which is why
      I have that code in a compile guard.

-- Any info on compatibility of OSSIM with C++11?

-- The output still seems to be wrong:
        Should be radians, according to ossimThreeParamsDatum.h

//////////////////////// Output /////////////////////////////////////////
ossimWgs84Datum:
param1(dX)= 0
param2(dY)= 0
param3(dZ)= 0
param4(N/A)= 0
param5(N/A)= 0
param6(N/A)= 0
param7(N/A)= 1
westLongitude= -180
eastLongitude= 180
southLatitude= -90
northLatitude= 90
sigmaX= 0
sigmaY= 0
sigmaZ= 0
code= WGE
name= World Geodetic System 1984
epsgCode= 6326

//////////////////////////// Source Code (updated) ///////////////////////
#include <iostream>
#include "ossim/base/ossimWgs84Datum.h"

// When set to true, ossim initialize is used
#define USE_INIT 0

#include "ossim/base/ossimEllipsoidFactory.h"
#include "ossim/base/ossimEpsgDatumFactory.h"

#if USE_INIT
   #include "ossim/init/ossimInit.h"
#endif

using namespace std;

int main( int argc, char* argv[] )
{
#if USE_INIT
   ossimInit::instance()->initialize( argc, argv );
#endif

   ossimWgs84Datum wgs84;

   cout << "ossimWgs84Datum:" << endl;
   cout << "param1(dX)= " << wgs84.param1() << endl;
   cout << "param2(dY)= " << wgs84.param2() << endl;
   cout << "param3(dZ)= " << wgs84.param3() << endl;
   cout << "param4(N/A)= " << wgs84.param4() << endl;
   cout << "param5(N/A)= " << wgs84.param5() << endl;
   cout << "param6(N/A)= " << wgs84.param6() << endl;
   cout << "param7(N/A)= " << wgs84.param7() << endl;

   cout << "westLongitude= " << wgs84.westLongitude() << endl;
   cout << "eastLongitude= " << wgs84.eastLongitude() << endl;
   cout << "southLatitude= " << wgs84.southLatitude() << endl;
   cout << "northLatitude= " << wgs84.northLatitude() << endl;
      cout << "sigmaX= " << wgs84.sigmaX() << endl;
   cout << "sigmaY= " << wgs84.sigmaY() << endl;
   cout << "sigmaZ= " << wgs84.sigmaZ() << endl;

   cout << "code= " << wgs84.code() << endl;
   cout << "name= " << wgs84.name() << endl;
   cout << "epsgCode= " << wgs84.epsgCode() << endl;

   delete ossimEllipsoidFactory::instance();
   delete ossimEpsgDatumFactory::instance();

   return 0;
}// main




<tossim.vgd>------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk_______________________________________________
www.ossim.org
Ossim-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/ossim-developer




------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk


_______________________________________________
www.ossim.org
Ossim-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/ossim-developer


------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
www.ossim.org
Ossim-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/ossim-developer
Reply | Threaded
Open this post in threaded view
|

Re: ossim newbie

Garrett Potts-2
Hello DAve and Norman:

What's strange is that the leak is tracing into the STL vector library for gcc.  I'll see if I can do ports on the current MAC.  It is running gcc 4.2.1 instead of the 4.7.X I saw on Norman's  run.  I am not sure if valgrind is getting confused with the const * for it is not an allocated and passed in pointer it is the "this" pointer of an allocated object.  Will have to rebuild here with full debug on.


Take care

Garrett

On Jul 24, 2013, at 1:01 PM, David Burken <[hidden email]> wrote:

Hey thanks Norman,

So we just introduced a "definitely lost"?

I was doing a valgrind run as we speak.  We build on a variety of platforms, mac osx, linux's, Fedora, RH EN, CentOS, windoze...

Dave

On 07/24/2013 12:15 PM, Norman Goldstein wrote:
I removed, downloaded and rebuilt. Attached is the new valgrind log.  Same source code as below.  The valgrind command is

valgrind --leak-check=full --fullpath-after= ./tossim

The leak summary is

==17023== LEAK SUMMARY:
==17023==    definitely lost: 784 bytes in 52 blocks
==17023==    indirectly lost: 0 bytes in 0 blocks
==17023==      possibly lost: 0 bytes in 0 blocks
==17023==    still reachable: 2,064 bytes in 2 blocks
==17023==         suppressed: 0 bytes in 0 blocks

Previously, there were no "definately lost", only "still reachable".  For this log, I did not give the "--show-reachable=yes" to valgrind.  (The path to redemption has its twists and bumps :-) ).

If you can think of further ways I can help, in addition running valgrind, please let me know.  What system are you building on?

Thank you,
Norm



On 07/24/2013 04:51 AM, Garrett Potts wrote:
Hello Norman:

I looked at the RTTI stuff and I refactored the array to use std::vector and name to use std::string.  Could you update and see if any of the RTTI items go away.  The RTTItypeinfo constructor and destructors are being called.  Tried a refactor of the arrays to see if this is throwing valgrind off.


Take care

Garrett

On Jul 22, 2013, at 4:18 PM, Norman Goldstein [hidden email] wrote:

On 07/22/2013 05:10 AM, Garrett Potts wrote:
2. The memory management is not clean

A lot of these are going to be false positives for parts of the singletons rely on the memory getting re-pooled on termination.  For example, the ossimTrace are statically allocated in cpp files and added to the trace manager for setting flags.  The ossimTrace destructor when pooled will un register itself from the manager before fully pooled back to the memory heap.  If you want to test the ossimTrace destruction add a print statement to the destructor and run the ossim-foo application again.
I added an explicit destructor to ossimTraceManager.cpp

ossimTraceManager::~ossimTraceManager()
{
   std::cout << "In ossimTraceManager::~ossimTraceManager()"
         << std::endl;
}

and the declaration in ossimTraceManager.h.   But as you can see from
the output, below, the destructor message is not printed to the screen.
I rebuilt ossim by
make clean
make
make install


A lot of the valgrinds are probably going to give what it thinks are leaks in the singletons.  We just need to go through the report and weed out valid and invalid leak detections.


Thank you and if you have a full valgrind log you can send that on.


Thanks, Garrett.  I think it is important to have a clean valgrind report,
perhaps after adding suppressions that we are positive should be
suppressed.

At the bottom of main (see below, please), are two "delete" lines that I
am not comfortable with, even though they greatly improve the valgrind
report.  They may be having side effects / incompatible with ossim code.

-- Attached is the valgrind output of the command
       valgrind --leak-check=full --show-reachable=yes --fullpath-after= ./tossim
    Without the "show-reachable" flag, no messages are printed, only the same
    leak summary at the bottom.

  -- When using the ossim initialize, I get a memory error, which is why
      I have that code in a compile guard.

-- Any info on compatibility of OSSIM with C++11?

-- The output still seems to be wrong:
        Should be radians, according to ossimThreeParamsDatum.h

//////////////////////// Output /////////////////////////////////////////
ossimWgs84Datum:
param1(dX)= 0
param2(dY)= 0
param3(dZ)= 0
param4(N/A)= 0
param5(N/A)= 0
param6(N/A)= 0
param7(N/A)= 1
westLongitude= -180
eastLongitude= 180
southLatitude= -90
northLatitude= 90
sigmaX= 0
sigmaY= 0
sigmaZ= 0
code= WGE
name= World Geodetic System 1984
epsgCode= 6326

//////////////////////////// Source Code (updated) ///////////////////////
#include <iostream>
#include "ossim/base/ossimWgs84Datum.h"

// When set to true, ossim initialize is used
#define USE_INIT 0

#include "ossim/base/ossimEllipsoidFactory.h"
#include "ossim/base/ossimEpsgDatumFactory.h"

#if USE_INIT
   #include "ossim/init/ossimInit.h"
#endif

using namespace std;

int main( int argc, char* argv[] )
{
#if USE_INIT
   ossimInit::instance()->initialize( argc, argv );
#endif

   ossimWgs84Datum wgs84;

   cout << "ossimWgs84Datum:" << endl;
   cout << "param1(dX)= " << wgs84.param1() << endl;
   cout << "param2(dY)= " << wgs84.param2() << endl;
   cout << "param3(dZ)= " << wgs84.param3() << endl;
   cout << "param4(N/A)= " << wgs84.param4() << endl;
   cout << "param5(N/A)= " << wgs84.param5() << endl;
   cout << "param6(N/A)= " << wgs84.param6() << endl;
   cout << "param7(N/A)= " << wgs84.param7() << endl;

   cout << "westLongitude= " << wgs84.westLongitude() << endl;
   cout << "eastLongitude= " << wgs84.eastLongitude() << endl;
   cout << "southLatitude= " << wgs84.southLatitude() << endl;
   cout << "northLatitude= " << wgs84.northLatitude() << endl;
      cout << "sigmaX= " << wgs84.sigmaX() << endl;
   cout << "sigmaY= " << wgs84.sigmaY() << endl;
   cout << "sigmaZ= " << wgs84.sigmaZ() << endl;

   cout << "code= " << wgs84.code() << endl;
   cout << "name= " << wgs84.name() << endl;
   cout << "epsgCode= " << wgs84.epsgCode() << endl;

   delete ossimEllipsoidFactory::instance();
   delete ossimEpsgDatumFactory::instance();

   return 0;
}// main




<tossim.vgd>------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk_______________________________________________
www.ossim.org
Ossim-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/ossim-developer




------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk


_______________________________________________
www.ossim.org
Ossim-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/ossim-developer

------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk_______________________________________________
www.ossim.org
Ossim-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/ossim-developer


------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
www.ossim.org
Ossim-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/ossim-developer
Reply | Threaded
Open this post in threaded view
|

Re: ossim newbie

jim hopper
Re: [OSSIM] ossim newbie Garrett,

If you are at 10.7 or above on Mac the default compiler is no long gcc 4.2 its using clang.

You  might find this interesting:
http://yamacdev.blogspot.com/2008/10/valgrind.html

On 7/24/13 1:17 PM, "Garrett Potts" <gcpotts@...> wrote:

Hello DAve and Norman:

What's strange is that the leak is tracing into the STL vector library for gcc.  I'll see if I can do ports on the current MAC.  It is running gcc 4.2.1 instead of the 4.7.X I saw on Norman's  run.  I am not sure if valgrind is getting confused with the const * for it is not an allocated and passed in pointer it is the "this" pointer of an allocated object.  Will have to rebuild here with full debug on.


Take care

Garrett

On Jul 24, 2013, at 1:01 PM, David Burken <dburken@...> wrote:

   
 Hey thanks Norman,
 
 So we just introduced a "definitely lost"?
 
 I was doing a valgrind run as we speak.  We build on a variety of platforms, mac osx, linux's, Fedora, RH EN, CentOS, windoze...
 
 Dave
 
 
On 07/24/2013 12:15 PM, Norman Goldstein wrote:
 
 
I removed, downloaded and rebuilt. Attached is the new valgrind log.  Same source code as below.  The valgrind command is
 
 valgrind --leak-check=full --fullpath-after= ./tossim
 
 The leak summary is
 
 ==17023== LEAK SUMMARY:
 ==17023==    definitely lost: 784 bytes in 52 blocks
 ==17023==    indirectly lost: 0 bytes in 0 blocks
 ==17023==      possibly lost: 0 bytes in 0 blocks
 ==17023==    still reachable: 2,064 bytes in 2 blocks
 ==17023==         suppressed: 0 bytes in 0 blocks
 
 Previously, there were no "definately lost", only "still reachable".  For this log, I did not give the "--show-reachable=yes" to valgrind.  (The path to redemption has its twists and bumps :-) ).
 
 If you can think of further ways I can help, in addition running valgrind, please let me know.  What system are you building on?
 
 Thank you,
 Norm
 
 
 
 On 07/24/2013 04:51 AM, Garrett Potts wrote:
 
Hello Norman:
 
 I looked at the RTTI stuff and I refactored the array to use std::vector and name to use std::string.  Could you update and see if any of the RTTI items go away.  The RTTItypeinfo constructor and destructors are being called.  Tried a refactor of the arrays to see if this is throwing valgrind off.
 
 
 Take care
 
 Garrett
 
 On Jul 22, 2013, at 4:18 PM, Norman Goldstein <normvcr@...> <[hidden email]>  wrote:
 
 
On 07/22/2013 05:10 AM, Garrett Potts wrote:
 
2. The memory management is not clean
 
 A lot of these are going to be false positives for parts of the singletons rely on the memory getting re-pooled on termination.  For example, the ossimTrace are statically allocated in cpp files and added to the trace manager for setting flags.  The ossimTrace destructor when pooled will un register itself from the manager before fully pooled back to the memory heap.  If you want to test the ossimTrace destruction add a print statement to the destructor and run the ossim-foo application again.
 
I added an explicit destructor to ossimTraceManager.cpp
 
 ossimTraceManager::~ossimTraceManager()
 {
    std::cout << "In ossimTraceManager::~ossimTraceManager()"
          << std::endl;
 }
 
 and the declaration in ossimTraceManager.h.   But as you can see from
 the output, below, the destructor message is not printed to the screen.
 I rebuilt ossim by
 make clean
 make
 make install
 
 

 A lot of the valgrinds are probably going to give what it thinks are leaks in the singletons.  We just need to go through the report and weed out valid and invalid leak detections.
 
 
 Thank you and if you have a full valgrind log you can send that on.
 
 
 
Thanks, Garrett.  I think it is important to have a clean valgrind report,
 perhaps after adding suppressions that we are positive should be
 suppressed.
 
 At the bottom of main (see below, please), are two "delete" lines that I
 am not comfortable with, even though they greatly improve the valgrind
 report.  They may be having side effects / incompatible with ossim code.
 
 -- Attached is the valgrind output of the command
        valgrind --leak-check=full --show-reachable=yes --fullpath-after= ./tossim
     Without the "show-reachable" flag, no messages are printed, only the same
     leak summary at the bottom.
 
   -- When using the ossim initialize, I get a memory error, which is why
       I have that code in a compile guard.
 
 -- Any info on compatibility of OSSIM with C++11?
 
 -- The output still seems to be wrong:
         Should be radians, according to ossimThreeParamsDatum.h
 
 //////////////////////// Output /////////////////////////////////////////
 ossimWgs84Datum:
 param1(dX)= 0
 param2(dY)= 0
 param3(dZ)= 0
 param4(N/A)= 0
 param5(N/A)= 0
 param6(N/A)= 0
 param7(N/A)= 1
 westLongitude= -180
 eastLongitude= 180
 southLatitude= -90
 northLatitude= 90
 sigmaX= 0
 sigmaY= 0
 sigmaZ= 0
 code= WGE
 name= World Geodetic System 1984
 epsgCode= 6326
 
 //////////////////////////// Source Code (updated) ///////////////////////
 #include <iostream>
 #include "ossim/base/ossimWgs84Datum.h"
 
 // When set to true, ossim initialize is used
 #define USE_INIT 0
 
 #include "ossim/base/ossimEllipsoidFactory.h"
 #include "ossim/base/ossimEpsgDatumFactory.h"
 
 #if USE_INIT
    #include "ossim/init/ossimInit.h"
 #endif
 
 using namespace std;
 
 int main( int argc, char* argv[] )
 {
 #if USE_INIT
    ossimInit::instance()->initialize( argc, argv );
 #endif
 
    ossimWgs84Datum wgs84;
 
    cout << "ossimWgs84Datum:" << endl;
    cout << "param1(dX)= " << wgs84.param1() << endl;
    cout << "param2(dY)= " << wgs84.param2() << endl;
    cout << "param3(dZ)= " << wgs84.param3() << endl;
    cout << "param4(N/A)= " << wgs84.param4() << endl;
    cout << "param5(N/A)= " << wgs84.param5() << endl;
    cout << "param6(N/A)= " << wgs84.param6() << endl;
    cout << "param7(N/A)= " << wgs84.param7() << endl;
 
    cout << "westLongitude= " << wgs84.westLongitude() << endl;
    cout << "eastLongitude= " << wgs84.eastLongitude() << endl;
    cout << "southLatitude= " << wgs84.southLatitude() << endl;
    cout << "northLatitude= " << wgs84.northLatitude() << endl;
       cout << "sigmaX= " << wgs84.sigmaX() << endl;
    cout << "sigmaY= " << wgs84.sigmaY() << endl;
    cout << "sigmaZ= " << wgs84.sigmaZ() << endl;
 
    cout << "code= " << wgs84.code() << endl;
    cout << "name= " << wgs84.name() << endl;
    cout << "epsgCode= " << wgs84.epsgCode() << endl;
 
    delete ossimEllipsoidFactory::instance();
    delete ossimEpsgDatumFactory::instance();
 
    return 0;
 }// main
 
 
 
 
<tossim.vgd>------------------------------------------------------------------------------
 See everything from the browser to the database with AppDynamics
 Get end-to-end visibility with application monitoring from AppDynamics
 Isolate bottlenecks and diagnose root cause in seconds.
 Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk_______________________________________________
 www.ossim.org <http://www.ossim.org/>  
 Ossim-developer mailing list
 Ossim-developer@...
 https://lists.sourceforge.net/lists/listinfo/ossim-developer
 

 

 
  
 
------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
 
  
 
_______________________________________________
www.ossim.org <http://www.ossim.org/>
Ossim-developer mailing list
Ossim-developer@...
https://lists.sourceforge.net/lists/listinfo/ossim-developer
 

 
------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk_______________________________________________
www.ossim.org
Ossim-developer mailing list
Ossim-developer@...
https://lists.sourceforge.net/lists/listinfo/ossim-developer



------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk

_______________________________________________
www.ossim.org
Ossim-developer mailing list
Ossim-developer@...
https://lists.sourceforge.net/lists/listinfo/ossim-developer

Jim  Hopper |
Software Application Engineer IV | National Security Sector | Integrated Systems Group
3745 Pentagon Blvd,
Beavercreek, OH 45431
Phone: 937-431-2336 | Mobile: 937-367-7252
James.e.hopper@... <[hidden email]>



 
 
NATIONAL SECURITY |  HEALTH  |  ENGINEERING
Science Applications International Corporation
This email and any attachments to it are intended only for the identified recipients. It may contain proprietary or otherwise legally protected information of SAIC. Any unauthorized use or disclosure of this communication is strictly prohibited. If you have received this communication in error, please notify the sender and delete or otherwise destroy the email and all attachments immediately.



------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
www.ossim.org
Ossim-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/ossim-developer
Reply | Threaded
Open this post in threaded view
|

Re: ossim newbie

Garrett Potts-2
Hello Jim:

Thank you man!


Take care

Garrett

On Jul 24, 2013, at 4:58 PM, jim hopper <[hidden email]> wrote:

Re: [OSSIM] ossim newbie
Garrett,

If you are at 10.7 or above on Mac the default compiler is no long gcc 4.2 its using clang.

You  might find this interesting:
http://yamacdev.blogspot.com/2008/10/valgrind.html

On 7/24/13 1:17 PM, "Garrett Potts" <<a href="x-msg://334/gcpotts@mac.com">gcpotts@...> wrote:

Hello DAve and Norman:

What's strange is that the leak is tracing into the STL vector library for gcc.  I'll see if I can do ports on the current MAC.  It is running gcc 4.2.1 instead of the 4.7.X I saw on Norman's  run.  I am not sure if valgrind is getting confused with the const * for it is not an allocated and passed in pointer it is the "this" pointer of an allocated object.  Will have to rebuild here with full debug on.


Take care

Garrett

On Jul 24, 2013, at 1:01 PM, David Burken <<a href="x-msg://334/dburken@comcast.net">dburken@...> wrote:

   
 Hey thanks Norman,
 
 So we just introduced a "definitely lost"?
 
 I was doing a valgrind run as we speak.  We build on a variety of platforms, mac osx, linux's, Fedora, RH EN, CentOS, windoze...
 
 Dave
 
 
On 07/24/2013 12:15 PM, Norman Goldstein wrote:
 
 
I removed, downloaded and rebuilt. Attached is the new valgrind log.  Same source code as below.  The valgrind command is
 
 valgrind --leak-check=full --fullpath-after= ./tossim
 
 The leak summary is
 
 ==17023== LEAK SUMMARY:
 ==17023==    definitely lost: 784 bytes in 52 blocks
 ==17023==    indirectly lost: 0 bytes in 0 blocks
 ==17023==      possibly lost: 0 bytes in 0 blocks
 ==17023==    still reachable: 2,064 bytes in 2 blocks
 ==17023==         suppressed: 0 bytes in 0 blocks
 
 Previously, there were no "definately lost", only "still reachable".  For this log, I did not give the "--show-reachable=yes" to valgrind.  (The path to redemption has its twists and bumps :-) ).
 
 If you can think of further ways I can help, in addition running valgrind, please let me know.  What system are you building on?
 
 Thank you,
 Norm
 
 
 
 On 07/24/2013 04:51 AM, Garrett Potts wrote:
 
Hello Norman:
 
 I looked at the RTTI stuff and I refactored the array to use std::vector and name to use std::string.  Could you update and see if any of the RTTI items go away.  The RTTItypeinfo constructor and destructors are being called.  Tried a refactor of the arrays to see if this is throwing valgrind off.
 
 
 Take care
 
 Garrett
 
 On Jul 22, 2013, at 4:18 PM, Norman Goldstein <<a href="x-msg://334/normvcr@telus.net">normvcr@...> <[hidden email]>  wrote:
 
 
On 07/22/2013 05:10 AM, Garrett Potts wrote:
 
2. The memory management is not clean
 
 A lot of these are going to be false positives for parts of the singletons rely on the memory getting re-pooled on termination.  For example, the ossimTrace are statically allocated in cpp files and added to the trace manager for setting flags.  The ossimTrace destructor when pooled will un register itself from the manager before fully pooled back to the memory heap.  If you want to test the ossimTrace destruction add a print statement to the destructor and run the ossim-foo application again.
 
I added an explicit destructor to ossimTraceManager.cpp
 
 ossimTraceManager::~ossimTraceManager()
 {
    std::cout << "In ossimTraceManager::~ossimTraceManager()"
          << std::endl;
 }
 
 and the declaration in ossimTraceManager.h.   But as you can see from
 the output, below, the destructor message is not printed to the screen.
 I rebuilt ossim by
 make clean
 make
 make install
 
 

 A lot of the valgrinds are probably going to give what it thinks are leaks in the singletons.  We just need to go through the report and weed out valid and invalid leak detections.
 
 
 Thank you and if you have a full valgrind log you can send that on.
 
 
 
Thanks, Garrett.  I think it is important to have a clean valgrind report,
 perhaps after adding suppressions that we are positive should be
 suppressed.
 
 At the bottom of main (see below, please), are two "delete" lines that I
 am not comfortable with, even though they greatly improve the valgrind
 report.  They may be having side effects / incompatible with ossim code.
 
 -- Attached is the valgrind output of the command
        valgrind --leak-check=full --show-reachable=yes --fullpath-after= ./tossim
     Without the "show-reachable" flag, no messages are printed, only the same
     leak summary at the bottom.
 
   -- When using the ossim initialize, I get a memory error, which is why
       I have that code in a compile guard.
 
 -- Any info on compatibility of OSSIM with C++11?
 
 -- The output still seems to be wrong:
         Should be radians, according to ossimThreeParamsDatum.h
 
 //////////////////////// Output /////////////////////////////////////////
 ossimWgs84Datum:
 param1(dX)= 0
 param2(dY)= 0
 param3(dZ)= 0
 param4(N/A)= 0
 param5(N/A)= 0
 param6(N/A)= 0
 param7(N/A)= 1
 westLongitude= -180
 eastLongitude= 180
 southLatitude= -90
 northLatitude= 90
 sigmaX= 0
 sigmaY= 0
 sigmaZ= 0
 code= WGE
 name= World Geodetic System 1984
 epsgCode= 6326
 
 //////////////////////////// Source Code (updated) ///////////////////////
 #include <iostream>
 #include "ossim/base/ossimWgs84Datum.h"
 
 // When set to true, ossim initialize is used
 #define USE_INIT 0
 
 #include "ossim/base/ossimEllipsoidFactory.h"
 #include "ossim/base/ossimEpsgDatumFactory.h"
 
 #if USE_INIT
    #include "ossim/init/ossimInit.h"
 #endif
 
 using namespace std;
 
 int main( int argc, char* argv[] )
 {
 #if USE_INIT
    ossimInit::instance()->initialize( argc, argv );
 #endif
 
    ossimWgs84Datum wgs84;
 
    cout << "ossimWgs84Datum:" << endl;
    cout << "param1(dX)= " << wgs84.param1() << endl;
    cout << "param2(dY)= " << wgs84.param2() << endl;
    cout << "param3(dZ)= " << wgs84.param3() << endl;
    cout << "param4(N/A)= " << wgs84.param4() << endl;
    cout << "param5(N/A)= " << wgs84.param5() << endl;
    cout << "param6(N/A)= " << wgs84.param6() << endl;
    cout << "param7(N/A)= " << wgs84.param7() << endl;
 
    cout << "westLongitude= " << wgs84.westLongitude() << endl;
    cout << "eastLongitude= " << wgs84.eastLongitude() << endl;
    cout << "southLatitude= " << wgs84.southLatitude() << endl;
    cout << "northLatitude= " << wgs84.northLatitude() << endl;
       cout << "sigmaX= " << wgs84.sigmaX() << endl;
    cout << "sigmaY= " << wgs84.sigmaY() << endl;
    cout << "sigmaZ= " << wgs84.sigmaZ() << endl;
 
    cout << "code= " << wgs84.code() << endl;
    cout << "name= " << wgs84.name() << endl;
    cout << "epsgCode= " << wgs84.epsgCode() << endl;
 
    delete ossimEllipsoidFactory::instance();
    delete ossimEpsgDatumFactory::instance();
 
    return 0;
 }// main
 
 
 
 
<tossim.vgd>------------------------------------------------------------------------------
 See everything from the browser to the database with AppDynamics
 Get end-to-end visibility with application monitoring from AppDynamics
 Isolate bottlenecks and diagnose root cause in seconds.
 Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk_______________________________________________
 www.ossim.org <http://www.ossim.org/>  
 Ossim-developer mailing list
 <a href="x-msg://334/Ossim-developer@lists.sourceforge.net">Ossim-developer@...
 https://lists.sourceforge.net/lists/listinfo/ossim-developer
 

 

 
  
 
------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
 
  
 
_______________________________________________
www.ossim.org <http://www.ossim.org/>
Ossim-developer mailing list
<a href="x-msg://334/Ossim-developer@lists.sourceforge.net">Ossim-developer@...
https://lists.sourceforge.net/lists/listinfo/ossim-developer
 

 
------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk_______________________________________________
www.ossim.org
Ossim-developer mailing list
<a href="x-msg://334/Ossim-developer@lists.sourceforge.net">Ossim-developer@...
https://lists.sourceforge.net/lists/listinfo/ossim-developer



------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk

_______________________________________________
www.ossim.org
Ossim-developer mailing list
<a href="x-msg://334/Ossim-developer@lists.sourceforge.net">Ossim-developer@...
https://lists.sourceforge.net/lists/listinfo/ossim-developer

Jim  Hopper |
Software Application Engineer IV | National Security Sector | Integrated Systems Group
3745 Pentagon Blvd,
Beavercreek, OH 45431
Phone: 937-431-2336 | Mobile: 937-367-7252
<a href="x-msg://334/James.e.hopper@saic.com">James.e.hopper@... <[hidden email]>


<image.jpg>
 
 
NATIONAL SECURITY |  HEALTH  |  ENGINEERING
Science Applications International Corporation
This email and any attachments to it are intended only for the identified recipients. It may contain proprietary or otherwise legally protected information of SAIC. Any unauthorized use or disclosure of this communication is strictly prohibited. If you have received this communication in error, please notify the sender and delete or otherwise destroy the email and all attachments immediately.


------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk_______________________________________________
www.ossim.org
Ossim-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/ossim-developer


------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
www.ossim.org
Ossim-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/ossim-developer
Reply | Threaded
Open this post in threaded view
|

Re: ossim newbie

James E. Hopper-2
Just checked on 10.7 default is still gcc but you can reset env variables to clang to make that the default


On Jul 24, 2013, at 5:23 PM, Garrett Potts <[hidden email]> wrote:

Hello Jim:

Thank you man!


Take care

Garrett

On Jul 24, 2013, at 4:58 PM, jim hopper <[hidden email]> wrote:

Re: [OSSIM] ossim newbie
Garrett,

If you are at 10.7 or above on Mac the default compiler is no long gcc 4.2 its using clang.

You  might find this interesting:
http://yamacdev.blogspot.com/2008/10/valgrind.html

On 7/24/13 1:17 PM, "Garrett Potts" <<a href="x-msg://334/gcpotts@mac.com">gcpotts@...> wrote:

Hello DAve and Norman:

What's strange is that the leak is tracing into the STL vector library for gcc.  I'll see if I can do ports on the current MAC.  It is running gcc 4.2.1 instead of the 4.7.X I saw on Norman's  run.  I am not sure if valgrind is getting confused with the const * for it is not an allocated and passed in pointer it is the "this" pointer of an allocated object.  Will have to rebuild here with full debug on.


Take care

Garrett

On Jul 24, 2013, at 1:01 PM, David Burken <<a href="x-msg://334/dburken@comcast.net">dburken@...> wrote:

   
 Hey thanks Norman,
 
 So we just introduced a "definitely lost"?
 
 I was doing a valgrind run as we speak.  We build on a variety of platforms, mac osx, linux's, Fedora, RH EN, CentOS, windoze...
 
 Dave
 
 
On 07/24/2013 12:15 PM, Norman Goldstein wrote:
 
 
I removed, downloaded and rebuilt. Attached is the new valgrind log.  Same source code as below.  The valgrind command is
 
 valgrind --leak-check=full --fullpath-after= ./tossim
 
 The leak summary is
 
 ==17023== LEAK SUMMARY:
 ==17023==    definitely lost: 784 bytes in 52 blocks
 ==17023==    indirectly lost: 0 bytes in 0 blocks
 ==17023==      possibly lost: 0 bytes in 0 blocks
 ==17023==    still reachable: 2,064 bytes in 2 blocks
 ==17023==         suppressed: 0 bytes in 0 blocks
 
 Previously, there were no "definately lost", only "still reachable".  For this log, I did not give the "--show-reachable=yes" to valgrind.  (The path to redemption has its twists and bumps :-) ).
 
 If you can think of further ways I can help, in addition running valgrind, please let me know.  What system are you building on?
 
 Thank you,
 Norm
 
 
 
 On 07/24/2013 04:51 AM, Garrett Potts wrote:
 
Hello Norman:
 
 I looked at the RTTI stuff and I refactored the array to use std::vector and name to use std::string.  Could you update and see if any of the RTTI items go away.  The RTTItypeinfo constructor and destructors are being called.  Tried a refactor of the arrays to see if this is throwing valgrind off.
 
 
 Take care
 
 Garrett
 
 On Jul 22, 2013, at 4:18 PM, Norman Goldstein <<a href="x-msg://334/normvcr@telus.net">normvcr@...> <[hidden email]>  wrote:
 
 
On 07/22/2013 05:10 AM, Garrett Potts wrote:
 
2. The memory management is not clean
 
 A lot of these are going to be false positives for parts of the singletons rely on the memory getting re-pooled on termination.  For example, the ossimTrace are statically allocated in cpp files and added to the trace manager for setting flags.  The ossimTrace destructor when pooled will un register itself from the manager before fully pooled back to the memory heap.  If you want to test the ossimTrace destruction add a print statement to the destructor and run the ossim-foo application again.
 
I added an explicit destructor to ossimTraceManager.cpp
 
 ossimTraceManager::~ossimTraceManager()
 {
    std::cout << "In ossimTraceManager::~ossimTraceManager()"
          << std::endl;
 }
 
 and the declaration in ossimTraceManager.h.   But as you can see from
 the output, below, the destructor message is not printed to the screen.
 I rebuilt ossim by
 make clean
 make
 make install
 
 

 A lot of the valgrinds are probably going to give what it thinks are leaks in the singletons.  We just need to go through the report and weed out valid and invalid leak detections.
 
 
 Thank you and if you have a full valgrind log you can send that on.
 
 
 
Thanks, Garrett.  I think it is important to have a clean valgrind report,
 perhaps after adding suppressions that we are positive should be
 suppressed.
 
 At the bottom of main (see below, please), are two "delete" lines that I
 am not comfortable with, even though they greatly improve the valgrind
 report.  They may be having side effects / incompatible with ossim code.
 
 -- Attached is the valgrind output of the command
        valgrind --leak-check=full --show-reachable=yes --fullpath-after= ./tossim
     Without the "show-reachable" flag, no messages are printed, only the same
     leak summary at the bottom.
 
   -- When using the ossim initialize, I get a memory error, which is why
       I have that code in a compile guard.
 
 -- Any info on compatibility of OSSIM with C++11?
 
 -- The output still seems to be wrong:
         Should be radians, according to ossimThreeParamsDatum.h
 
 //////////////////////// Output /////////////////////////////////////////
 ossimWgs84Datum:
 param1(dX)= 0
 param2(dY)= 0
 param3(dZ)= 0
 param4(N/A)= 0
 param5(N/A)= 0
 param6(N/A)= 0
 param7(N/A)= 1
 westLongitude= -180
 eastLongitude= 180
 southLatitude= -90
 northLatitude= 90
 sigmaX= 0
 sigmaY= 0
 sigmaZ= 0
 code= WGE
 name= World Geodetic System 1984
 epsgCode= 6326
 
 //////////////////////////// Source Code (updated) ///////////////////////
 #include <iostream>
 #include "ossim/base/ossimWgs84Datum.h"
 
 // When set to true, ossim initialize is used
 #define USE_INIT 0
 
 #include "ossim/base/ossimEllipsoidFactory.h"
 #include "ossim/base/ossimEpsgDatumFactory.h"
 
 #if USE_INIT
    #include "ossim/init/ossimInit.h"
 #endif
 
 using namespace std;
 
 int main( int argc, char* argv[] )
 {
 #if USE_INIT
    ossimInit::instance()->initialize( argc, argv );
 #endif
 
    ossimWgs84Datum wgs84;
 
    cout << "ossimWgs84Datum:" << endl;
    cout << "param1(dX)= " << wgs84.param1() << endl;
    cout << "param2(dY)= " << wgs84.param2() << endl;
    cout << "param3(dZ)= " << wgs84.param3() << endl;
    cout << "param4(N/A)= " << wgs84.param4() << endl;
    cout << "param5(N/A)= " << wgs84.param5() << endl;
    cout << "param6(N/A)= " << wgs84.param6() << endl;
    cout << "param7(N/A)= " << wgs84.param7() << endl;
 
    cout << "westLongitude= " << wgs84.westLongitude() << endl;
    cout << "eastLongitude= " << wgs84.eastLongitude() << endl;
    cout << "southLatitude= " << wgs84.southLatitude() << endl;
    cout << "northLatitude= " << wgs84.northLatitude() << endl;
       cout << "sigmaX= " << wgs84.sigmaX() << endl;
    cout << "sigmaY= " << wgs84.sigmaY() << endl;
    cout << "sigmaZ= " << wgs84.sigmaZ() << endl;
 
    cout << "code= " << wgs84.code() << endl;
    cout << "name= " << wgs84.name() << endl;
    cout << "epsgCode= " << wgs84.epsgCode() << endl;
 
    delete ossimEllipsoidFactory::instance();
    delete ossimEpsgDatumFactory::instance();
 
    return 0;
 }// main
 
 
 
 
<tossim.vgd>------------------------------------------------------------------------------
 See everything from the browser to the database with AppDynamics
 Get end-to-end visibility with application monitoring from AppDynamics
 Isolate bottlenecks and diagnose root cause in seconds.
 Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk_______________________________________________
 www.ossim.org <http://www.ossim.org/>  
 Ossim-developer mailing list
 <a href="x-msg://334/Ossim-developer@lists.sourceforge.net">Ossim-developer@...
 https://lists.sourceforge.net/lists/listinfo/ossim-developer
 

 

 
  
 
------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
 
  
 
_______________________________________________
www.ossim.org <http://www.ossim.org/>
Ossim-developer mailing list
<a href="x-msg://334/Ossim-developer@lists.sourceforge.net">Ossim-developer@...
https://lists.sourceforge.net/lists/listinfo/ossim-developer
 

 
------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk_______________________________________________
www.ossim.org
Ossim-developer mailing list
<a href="x-msg://334/Ossim-developer@lists.sourceforge.net">Ossim-developer@...
https://lists.sourceforge.net/lists/listinfo/ossim-developer



------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk

_______________________________________________
www.ossim.org
Ossim-developer mailing list
<a href="x-msg://334/Ossim-developer@lists.sourceforge.net">Ossim-developer@...
https://lists.sourceforge.net/lists/listinfo/ossim-developer

Jim  Hopper |
Software Application Engineer IV | National Security Sector | Integrated Systems Group
3745 Pentagon Blvd,
Beavercreek, OH 45431
Phone: 937-431-2336 | Mobile: 937-367-7252
<a href="x-msg://334/James.e.hopper@saic.com">James.e.hopper@... <[hidden email]>


<image.jpg>
 
 
NATIONAL SECURITY |  HEALTH  |  ENGINEERING
Science Applications International Corporation
This email and any attachments to it are intended only for the identified recipients. It may contain proprietary or otherwise legally protected information of SAIC. Any unauthorized use or disclosure of this communication is strictly prohibited. If you have received this communication in error, please notify the sender and delete or otherwise destroy the email and all attachments immediately.


------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk_______________________________________________
www.ossim.org
Ossim-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/ossim-developer

------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
www.ossim.org
Ossim-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/ossim-developer

------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
www.ossim.org
Ossim-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/ossim-developer