[Gc] GC as leak detecto

Boehm, Hans hans.boehm at hp.com
Mon Oct 10 14:49:03 PDT 2005


That looks like something (the collector itself?) is allocating
pointer-free memory.

I can't immediately reproduce the problem.

I expect there should be very few, and possibly no, calls to
GC_malloc_atomic in your environment, possibly aside from those
introduced by your operator new.  Can you put a breakpoint there, and
see who might be allocating "atomic" objects? 

I would replace your own calls to the "atomic" allocator by calls to the
regular allocator for this experiment.  (If the problem goes away as a
result, that would already be interesting.

Hans
 

> -----Original Message-----
> From: gc-bounces at napali.hpl.hp.com 
> [mailto:gc-bounces at napali.hpl.hp.com] On Behalf Of Juan Jose 
> Garcia Ripoll
> Sent: Friday, October 07, 2005 5:30 AM
> To: gc at napali.hpl.hp.com
> Subject: [Gc] GC as leak detecto
> 
> 
> [Sorry for possible duplicates]
> 
> Hi,
> 
>   these days I have been using the garbage collector to 
> investigate the memory use and potential leaks in a C++ 
> program. To get the most of the information I have done the following:
> 
> 1) Configure the GC with --disable-threads 
> --disable-cplusplus --enable-full-debug --enable-redirect-malloc
> 
> 2) Define my own new/delete operators as indicated below.
>    All routines in my program use the defined new/delete operators.
> 
> 3) Somewhere in my program, these statements are executed:
>         GC_find_leak = 1;
>         GC_start_debugging();
> 
> Now, when I run the program I get lines like 
> 
>         Leaked atomic object at start: 0x8138e40, appr. length: 64
>         Leaked atomic object at start: 0x8138ec0, appr. length: 64
>         Leaked atomic object at start: 0x81350c0, appr. length: 64
>         Leaked atomic object at start: 0x8135200, appr. length: 64
> 
> The problem is that there is no debug information in them. I 
> have tried to track down where these pointers come from or 
> where they are generated without much success. The system 
> routines malloc/free seem to be actually replaced by the 
> debug ones from the garbage collector, and if I set a watch 
> point in any of the above pointers I typically end up in 
> GC_store_debug_info.
> 
> I am using the version 6.5 of the garbage collector in a 
> Linux Ubuntu 5.04. Can it be that the garbage collector is 
> getting confused and those leaks do not exist? Or is my 
> program probably smashing the debug region of these pointers?
> 
> Running the same program in valgrind (without the GC of 
> course) does not seem to point any problems.
> 
> Regards
> 
> Juanjo
> 
> ---------
> inline void *operator new(size_t s, bool atomic, const char 
> *f, int i) {
>     if (atomic)
>         return GC_debug_malloc_atomic(s, f, i);
>     else
>         return GC_debug_malloc(s, f, i);
> }
> 
> inline void *operator new[](size_t s, bool atomic, const char 
> *f, int i) {
>     return ::operator new(s, atomic, f, i);
> }
> 
> void *operator new(size_t s)
> {
>     return GC_debug_malloc(s, __FILE__, __LINE__);
> }
> 
> void operator delete(void *p)
> {
>     return GC_debug_free(p);
> }
> void *operator new[](size_t s)
> {
>     return GC_debug_malloc(s, __FILE__, __LINE__);
> }
> 
> void operator delete[](void *p)
> {
>     return GC_debug_free(p);
> }
> 
> 
> 
> _______________________________________________
> Gc mailing list
> Gc at linux.hpl.hp.com 
> http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
> 



More information about the Gc mailing list