Re: [osg-users] Profiler with OSG
Hi @Sergey : I currently do it, but it returns me a lot of leak, and a lot looks like false positive... Thanks Jean-Sébastien for AQTime ans gDebugger, I'll have a look at these. Thibault, thanks a lot for this very detailed answer. I think I will find my problems with all these possibilities. Thanks a lot, I'll tell you if I find an easy solution to find memory leaks. Regards, Vincent. 2008/9/19 Jean-Sébastien Guay <[EMAIL PROTECTED]> > Hi Vincent, > > No one never profile his OSG code ? >> > > I think everyone has different ways of working. I tend to evaluate > performance with the Stats Handler and try out different variations of > algorithms to see which one performs better. I've rarely needed to do actual > profiling. > > When I did need to, I've used AQTime and gDebugger for general and OpenGL > profiling respectively. Neither is free though. > > Apparently if you're on Linux you can use valgrind to find memory leaks > (and I hear that either it understands ref_ptr natively or there's a > workaround to eliminate the related false positives) and oprofile to profile > your code. I don't work on Linux enough to have had to use them myself > though. > > Sorry I can't help more, > > J-S > -- > __ > Jean-Sebastien Guay[EMAIL PROTECTED] > http://www.cm-labs.com/ >http://whitestar02.webhop.org/ > > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Profiler with OSG
Hi Vincent, No one never profile his OSG code ? I think everyone has different ways of working. I tend to evaluate performance with the Stats Handler and try out different variations of algorithms to see which one performs better. I've rarely needed to do actual profiling. When I did need to, I've used AQTime and gDebugger for general and OpenGL profiling respectively. Neither is free though. Apparently if you're on Linux you can use valgrind to find memory leaks (and I hear that either it understands ref_ptr natively or there's a workaround to eliminate the related false positives) and oprofile to profile your code. I don't work on Linux enough to have had to use them myself though. Sorry I can't help more, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Profiler with OSG
Hi Vincent
On Fri, Sep 19, 2008 at 2:08 PM, Vincent Bourdier
<[EMAIL PROTECTED]> wrote:
> Hi thibault
>
> I just have tried with the microsoft compiler. I still have some memory
> leaks, but the ouput is unreadable :
>
> [...]
> {431278} normal block at 0x12194A50, 108 bytes long.
> Data: < {\ > FC 7B 5C 10 00 00 00 00 01 00 00 00 00 00 00 00
> {431277} normal block at 0x12194A08, 12 bytes long.
> Data: 55 03 4F 03 54 03 50 03 53 03 52 03
> [...]
This is quite expected, unless you leak a memory block containing a
string. Anyway, the valuable information here is:
- the allocation number of the block (here, 431278 and 431277)
- the length (108 bytes and 12 bytes)
To chase the bug, you need to find the lowest allocation number that
results in a leak, since further allocations might be done by the
object that is leaking and fixing the first leak may fix others -
maybe all if you are lucky :)
Once you have this, you need to re-run your program a few times to see
if this allocation number changes. If it does, you are in trouble (see
below). If it does not, then what you need to do is to call
_CrtSetBreakAlloc();
at the beginning of the program and run it under the debugger. When
the allocation number is hit, you get a popup from the debugger and
you are pointed to the exact instruction that triggers the allocation.
With this information you can hopefully find why the memory block is
never freed.
If the allocation number changes from run to run, it means that there
is some kind of random process bothering you. This typically happens
in GUIs as the user moves the mouse pointer, triggering events that
allocate memory and it is impossible to recreate the exact same order
of allocations between two runs. Facing this kind of horror, two
techniques can help you:
- try to reduce the program by removing all interactions and any other
source of randomness until the leaking allocation number does not
change between runs
- track the allocation size with a hook. Let me explain this further:
You can place a hook (i.e. callback) for each allocation with the
function _CrtSetAllocHook():
First, our callback:
int MyAllocHook( int allocType, void *userData, size_t size, int
blockType, long requestNumber, const unsigned
char *filename, int
lineNumber)
{
// This is called upon each allocation. Return TRUE to allow
the allocation, FALSE to make it fail
return TRUE;
}
and then at the beginning of the program:
_CrtSetAllocHook(MyAllocHook)
Now your hook is called for each allocation. To find the mysterious
allocation that leaks, try to find a range of numbers (e.g. the first
block that leaks is almost always in 431000..431300) and use the
allocation size in an if test such as:
if (size == && requestNumber >= 431000 &&
requestNumber <= 431300)
int dummy = 0;
Place a breakpoint on the "int dummy=0" line. It will hopefully be hit
once during the faulty allocation. If it is hit more than once, try
to narrow the allocation range as much as you can.
You can as well use the hook instead of the _CrtSetBreakAlloc() call
since you are given the allocation number in it.
Hope this helps
Thibault
> I just need the line code where to find the leak but I am not able to do
> it... I added #define _CRTDBG_MAP_ALLOC but nothing appear...
> Any suggestion to get the file and line number ?
>
> thanks a lot.
> Regards,
> Vincent.
>
> 2008/9/19 Thibault Genessay <[EMAIL PROTECTED]>
>>
>> Hi Vincent
>>
>> On Fri, Sep 19, 2008 at 1:12 PM, Vincent Bourdier
>> <[EMAIL PROTECTED]> wrote:
>> > I know... but I am under windows... and so I have to forget this one...
>> > :'(
>> > No one under windows ?
>>
>> You could try IBM Rational Purify. It's quite a nice tool and you can
>> download a trial version.
>> (You can also try to port your code to Linux. You get a triple
>> benefit: you can cross-check your code for compiler-specific hidden
>> bugs, you can use Valgrind and your app will run under Linux.)
>>
>> > Searching memory leaks, I use some libraries looking at leaks but it is
>> > very difficult to know if a leak is really one or not, specially due to
>> > ref_prt<>.
>> > Is there any free profiler (memory, time, number of acces, ...) for
>> > windows or even for VS 2005 (not Team edition) to trace an OSG based
>> > program
>> > ?
>>
>> I've never come across difficulties with ref_ptrs themselves. If you
>> don't create circular dependencies, they will free the memory they
>> point to and the memory leak detector will not report a false
>> positive. If you use the Microsoft compiler, do you get any reports
>> when leak detection is turned on ? (i.e. by calling
>> _CrtSetDbgFlag(_CrtSetDbgFlag(_CRTDBG_REPORT_FLAG) |
>> (_CRTDBG_LEAK_CHECK_DF)); at the beginning of your program)
>> If you do have reports here you obviously have a memory leak due to a
>> programming error, not related to ref_ptrs.
>>
>> Regards
>>
>> Thibault
>>
Re: [osg-users] Profiler with OSG
Hello Vincent try visual memory leak detector http://dmoulding.googlepages.com/vld it is easy - just add a header and a lib then you get reports which lead to the lines in your code. Regards Sergey Kurdakov On Fri, Sep 19, 2008 at 4:08 PM, Vincent Bourdie ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Profiler with OSG
Hi thibault
I just have tried with the microsoft compiler. I still have some memory
leaks, but the ouput is unreadable :
[...]
{431278} normal block at 0x12194A50, 108 bytes long.
Data: < {\ > FC 7B 5C 10 00 00 00 00 01 00 00 00 00 00 00 00
{431277} normal block at 0x12194A08, 12 bytes long.
Data: 55 03 4F 03 54 03 50 03 53 03 52 03
[...]
I just need the line code where to find the leak but I am not able to do
it... I added #define _CRTDBG_MAP_ALLOC but nothing appear...
Any suggestion to get the file and line number ?
thanks a lot.
Regards,
Vincent.
2008/9/19 Thibault Genessay <[EMAIL PROTECTED]>
> Hi Vincent
>
> On Fri, Sep 19, 2008 at 1:12 PM, Vincent Bourdier
> <[EMAIL PROTECTED]> wrote:
> > I know... but I am under windows... and so I have to forget this one...
> :'(
> > No one under windows ?
>
> You could try IBM Rational Purify. It's quite a nice tool and you can
> download a trial version.
> (You can also try to port your code to Linux. You get a triple
> benefit: you can cross-check your code for compiler-specific hidden
> bugs, you can use Valgrind and your app will run under Linux.)
>
> > Searching memory leaks, I use some libraries looking at leaks but it is
> very difficult to know if a leak is really one or not, specially due to
> ref_prt<>.
> > Is there any free profiler (memory, time, number of acces, ...) for
> windows or even for VS 2005 (not Team edition) to trace an OSG based program
> ?
>
> I've never come across difficulties with ref_ptrs themselves. If you
> don't create circular dependencies, they will free the memory they
> point to and the memory leak detector will not report a false
> positive. If you use the Microsoft compiler, do you get any reports
> when leak detection is turned on ? (i.e. by calling
> _CrtSetDbgFlag(_CrtSetDbgFlag(_CRTDBG_REPORT_FLAG) |
> (_CRTDBG_LEAK_CHECK_DF)); at the beginning of your program)
> If you do have reports here you obviously have a memory leak due to a
> programming error, not related to ref_ptrs.
>
> Regards
>
> Thibault
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Profiler with OSG
Hi Vincent On Fri, Sep 19, 2008 at 1:12 PM, Vincent Bourdier <[EMAIL PROTECTED]> wrote: > I know... but I am under windows... and so I have to forget this one... :'( > No one under windows ? You could try IBM Rational Purify. It's quite a nice tool and you can download a trial version. (You can also try to port your code to Linux. You get a triple benefit: you can cross-check your code for compiler-specific hidden bugs, you can use Valgrind and your app will run under Linux.) > Searching memory leaks, I use some libraries looking at leaks but it is very > difficult to know if a leak is really one or not, specially due to ref_prt<>. > Is there any free profiler (memory, time, number of acces, ...) for windows > or even for VS 2005 (not Team edition) to trace an OSG based program ? I've never come across difficulties with ref_ptrs themselves. If you don't create circular dependencies, they will free the memory they point to and the memory leak detector will not report a false positive. If you use the Microsoft compiler, do you get any reports when leak detection is turned on ? (i.e. by calling _CrtSetDbgFlag(_CrtSetDbgFlag(_CRTDBG_REPORT_FLAG) | (_CRTDBG_LEAK_CHECK_DF)); at the beginning of your program) If you do have reports here you obviously have a memory leak due to a programming error, not related to ref_ptrs. Regards Thibault ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Profiler with OSG
I know... but I am under windows... and so I have to forget this one... :'( No one under windows ? Thanks. 2008/9/19 Alberto Luaces <[EMAIL PROTECTED]> > El Viernes 19 Septiembre 2008ES 13:00:57 Vincent Bourdier escribió: > > No one never profile his OSG code ? > > Yes, but with the Linux-only valgrind tool :) > > http://valgrind.org/ > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Profiler with OSG
El Viernes 19 Septiembre 2008ES 13:00:57 Vincent Bourdier escribió: > No one never profile his OSG code ? Yes, but with the Linux-only valgrind tool :) http://valgrind.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Profiler with OSG
No one never profile his OSG code ? I found a tool named visual leak detector... but it returns me a lot of leaks in OSG, I suppose in relation with ref_ptr<> For the moment I am looking at a memory leak detector only. (a profiler too, but it is too hard to find a free one) Thanks for help. Regards, Vincent. 2008/9/18 Vincent Bourdier <[EMAIL PROTECTED]> > Hi, > > Searching memory leaks, I use some libraries looking at leaks but it is > very difficult to know if a leak is really one or not, specially due to > ref_prt<>. > > Is there any free profiler (memory, time, number of acces, ...) for windows > or even for VS 2005 (not Team edition) to trace an OSG based program ? > > Thanks a lot. > > Regards, > Vincent. > ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
