[Gc] I_DONT_HOLD_LOCK removal in GC_print_obj and friends

Boehm, Hans hans.boehm at hp.com
Mon Nov 24 18:02:22 PST 2008


This doesn't look correct to me, since GC_print_callers acquires tha allocator lock, and on some platforms does all sorts of nasty stuff that might result in allocation with REDIRECT_MALLOC.  Is there a way to avoid acquiring the lock for this call?  I haven't had a chance to look in detail.

Hans

> -----Original Message-----
> From: gc-bounces at napali.hpl.hp.com
> [mailto:gc-bounces at napali.hpl.hp.com] On Behalf Of Ivan Maidanski
> Sent: Monday, October 27, 2008 8:49 AM
> To: gc at napali.hpl.hp.com
> Subject: [Gc] I_DONT_HOLD_LOCK removal in GC_print_obj and friends
>
> Hi!
>
> I_DONT_HOLD_LOCK() assertion is violated in
> GC_debug_print_heap_obj_proc() (called indirectly from
> GC_maybe_gc()) when test.c and gclib are compiled for Win32
> with -DALL_INTERIOR_POINTERS -DGC_THREADS -DGC_ASSERTIONS
> -DPRINT_BLACK_LIST -DDBG_HDRS_ALL.
>
> This assertion can't be replaced wih I_HOLD_LOCK() because it
> is violated too (called indirectly from GC_help_marker())
> when test.c and gclib are compiled for Win32 with
> -DALL_INTERIOR_POINTERS -DGC_THREADS -DGC_ASSERTIONS
> -DPRINT_BLACK_LIST -DDBG_HDRS_ALL -DPARALLEL_MARK
> -DAO_ASSUME_WINDOWS98.
>
> I don't know the purpose of this assertion.
> Since it works ok without this assertion (and in
> GC_print_obj(), and GC_print_smashed_obj()), the attached
> patch removes these assertions.
>
> PS. The same assertion in GC_print_all_smashed_() is ok.
>
> Bye.
>
>



More information about the Gc mailing list