[Gc] I_DONT_HOLD_LOCK removal in GC_print_obj and friends
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.
> -----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
> 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
> 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.
More information about the Gc