[Gc] GC as leak detecto

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/>