|
From: Bryan M. <om...@br...> - 2006-06-06 19:49:17
|
Dear Valgrinders, Is there a simple (read cheap) way to detect when the program has returned from main()? On Suse 10.1 (x86_64) I am having a few issues crop up with omega that I can easily fix, given a boolean or some such to show when function main is finished with. I suppose the most useful indication of all would be a bool that is set only whilst the program is somewhere within main or a function called from main. Failing that, a suggestion of where to add in an appropriate hook would also be helpful. I looked in m_stacktrace.c for clues but string comparison seems a little expensive for what would be quite a common check. Maybe integrating the indication with the stack retrieval in some fashion would do it (first stack request outside of main() sets the flag)? Thanks in advance, Bryan "Brain Murders" Meredith |
|
From: Julian S. <js...@ac...> - 2006-06-06 21:47:54
|
One grotty hack which has been used on more than one occasion is to find the return address, change it to point at some magic piece of code under your control, wait till you get there, do whatever, restore the real address, and continue. It's nasty. Not least because it's platform dependent. Much easier, cleaner and platform independent in the 3.2.0 line is to use function wrapping - just write a wrapper for main and put it in your tool's preload.so file. See wrap[1-8].c for examples; function wrapping is also pretty well documented. Uh .. why do you want to know when main has returned? Point is the returning of main does not mean the program has finished, especially not in a multithreaded environment. J On Tuesday 06 June 2006 20:48, Bryan Meredith wrote: > Dear Valgrinders, > > Is there a simple (read cheap) way to detect when the program has > returned from main()? > > On Suse 10.1 (x86_64) I am having a few issues crop up with omega that I > can easily fix, given a boolean or some such to show when function main > is finished with. I suppose the most useful indication of all would be a > bool that is set only whilst the program is somewhere within main or a > function called from main. > > Failing that, a suggestion of where to add in an appropriate hook would > also be helpful. > > I looked in m_stacktrace.c for clues but string comparison seems a > little expensive for what would be quite a common check. Maybe > integrating the indication with the stack retrieval in some fashion > would do it (first stack request outside of main() sets the flag)? > > Thanks in advance, > Bryan "Brain Murders" Meredith > > > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers |
|
From: Bryan M. <om...@br...> - 2006-06-07 19:59:20
|
Function wrapping - of course! - how elegant could it get?
I am interested because once a program has returned from main (and omega
has processed the stack unwind) there should be no more leak reports.
Any memory blocks that exist after the return must have
file/global/static scope pointers to them which remain valid. Stopping
tracking at this point would prevent 'random' data being mistaken as a
reference to a block, thus trashing an otherwise correct report:
> valgrind --instant-reports --tool=omega ./scope2
==5305== Omega-beta2, An instant memory leak detector.
==5305== Copyright (C) 2006, and GNU GPL'd, by Bryan Meredith.
==5305== Using LibVEX rev 1419, a library for dynamic binary translation.
==5305== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
==5305== Using valgrind-3.2.0rc1, a dynamic binary instrumentation
framework.
==5305== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.
==5305== For more details, rerun with: -v
==5305==
==5305== Probably leaking block of 64(0x40) bytes
==5305== at 0x400516: func1 (scope2.c:10)
==5305== by 0x40052B: main (scope2.c:14)
==5305== Block at 0x4D52028 allocated
==5305== at 0x4A2008E: malloc (vg_replace_malloc.c:149)
==5305== by 0x400511: func1 (scope2.c:7)
==5305== by 0x40052B: main (scope2.c:14)
--5305--
--5305-- Welcome back to the supposedly leaked block at 0x4D52028.
Illegal read?
==5305== at 0x400CB84: _dl_fini (in /lib64/ld-2.4.so)
==5305== by 0x4B54176: exit (in /lib64/libc-2.4.so)
==5305== by 0x4B3F15A: (below main) (in /lib64/libc-2.4.so)
--5305--
==5305== Probably leaking block of 64(0x40) bytes
==5305== at 0x400CC38: _dl_fini (in /lib64/ld-2.4.so)
==5305== by 0x4B54176: exit (in /lib64/libc-2.4.so)
==5305== by 0x4B3F15A: (below main) (in /lib64/libc-2.4.so)
==5305== Block at 0x4D52028 allocated
==5305== at 0x4A2008E: malloc (vg_replace_malloc.c:149)
==5305== by 0x400511: func1 (scope2.c:7)
==5305== by 0x40052B: main (scope2.c:14)
--5305--
==5305==
==5305==
==5305==
==5305== Omega Leak Summary
==5305== ==================
==5305== Loss Record 1: Leaked 64 (0x40) bytes in 1 block
==5305== at 0x400CC38: _dl_fini (in /lib64/ld-2.4.so)
==5305== by 0x4B54176: exit (in /lib64/libc-2.4.so)
==5305== by 0x4B3F15A: (below main) (in /lib64/libc-2.4.so)
==5305== Block allocated
==5305== at 0x4A2008E: malloc (vg_replace_malloc.c:149)
==5305== by 0x400511: func1 (scope2.c:7)
==5305== by 0x40052B: main (scope2.c:14)
==5305==
As you can see, the proper report got nuked by some 'random' data.
Knowing when main() has finished will allow me to block that.
I must admit, I had totally forgotten about threading support. The same
thing applies though, when the thread returns, any memory blocks that
remain will have valid pointers so processing can stop. The only issue
with threading is the cancellation point handling ("only issue" - should
that read "big issue"?). I suppose function wrapping could come to my
assistance here also, so long as I maintain a flag per thread. Removing
any tracked pointers within the whole of the thread's stack at thread
exit should sort most things (including leak report generation) but I
will have to test that.
Thanks for the help so far,
Bryan "Brain Murders" Meredith
Julian Seward wrote:
> One grotty hack which has been used on more than one occasion is to
> find the return address, change it to point at some magic piece of code
> under your control, wait till you get there, do whatever, restore the
> real address, and continue. It's nasty. Not least because it's
> platform dependent.
>
> Much easier, cleaner and platform independent in the 3.2.0 line is to
> use function wrapping - just write a wrapper for main and put it in
> your tool's preload.so file. See wrap[1-8].c for examples; function
> wrapping is also pretty well documented.
>
> Uh .. why do you want to know when main has returned? Point is
> the returning of main does not mean the program has finished,
> especially not in a multithreaded environment.
>
> J
>
>
> On Tuesday 06 June 2006 20:48, Bryan Meredith wrote:
>> Dear Valgrinders,
>>
>> Is there a simple (read cheap) way to detect when the program has
>> returned from main()?
>>
>> On Suse 10.1 (x86_64) I am having a few issues crop up with omega that I
>> can easily fix, given a boolean or some such to show when function main
>> is finished with. I suppose the most useful indication of all would be a
>> bool that is set only whilst the program is somewhere within main or a
>> function called from main.
>>
>> Failing that, a suggestion of where to add in an appropriate hook would
>> also be helpful.
>>
>> I looked in m_stacktrace.c for clues but string comparison seems a
>> little expensive for what would be quite a common check. Maybe
>> integrating the indication with the stack retrieval in some fashion
>> would do it (first stack request outside of main() sets the flag)?
>>
>> Thanks in advance,
>> Bryan "Brain Murders" Meredith
>>
>>
>> _______________________________________________
>> Valgrind-developers mailing list
>> Val...@li...
>> https://lists.sourceforge.net/lists/listinfo/valgrind-developers
>
|