Re[50]: [Gc]: GC + Windows Mobile + Threads + Patch for WINCE

Ivan Maidanski ivmai at mail.ru
Fri Nov 6 03:45:55 PST 2009


Hi!
Zeyi Lee <biosli at hotmail.com> wrote:
> Hi!
> > > > Ok. Retry without -DGC_GCJ_SUPPORT -DATOMIC_UNCOLLECTABLE -DTHREAD_LOCAL_ALLOC -DPARALLEL_MARK -DGC_ASSERTIONS -DMAKE_BACK_GRAPH. If it works without a Data Abort, try to find out which "define" option influences it (by adding them back one-by-one).
> > > 
> > > I test again with macro -DALL_INTERIOR_POINTERS -DGC_GCJ_SUPPORT -DATOMIC_UNCOLLECTABLE -DNO_DEBUGGING -DGC_THREADS -DUSE_MUNMAP -DTHREAD_LOCAL_ALLOC -DPARALLEL_MARK -DGC_ASSERTIONS -DMAKE_BACK_GRAPH -DGC_MIN_MARKERS=2 /link /stack:65536
> > > and -DVERY_SMALL_CONFIG
> > .............. 
> > Well, it looks like that problem hasn't been solved, you just hadn't run the test that many times to observe it. Try to set a breakpoint on "goto handle_ex" in mark.c and tell me whether it ever be hit (if yes then this is that old problem).
> 
>  
> 
> Yes, as you said the "goto handle_ex"(mark.c(GC_mark_some) Line: 519 ) was hit. It seems the old problem.

And you are not defining GC_REGISTER_MEM_PRIVATE, right? It's interesting what're the memory region attributes to which the address (raising Data Abort) belongs.

> 
> > The attachment tells me really little...
> > It seems like an object had allocated for GC_thread entry has remained marked as free and been reused at some place. But I don't the see how this happens...
> > 
> > I'd like to reproduce the case (on Win32). Tell me please:
> > - your OS, CPU cores count, your compiler;
> 
> OS: Windows XP Professional, SP 3.
> 
> CPU: 2 cores.
> 
> compiler: VS 2005 VC++ cl.exe 14.0.50727.762

for x86, right?

> 
> > - full list of parameters you compiled and linked test.c with (including the contents of stdafx.h if you still use it).
> ------------stdafx.h copy as following-------------
> 
> #define WIN32_LEAN_AND_MEAN
> #include <windows.h>
> #pragma warning(error: 4013) // function undefined; assuming extern returning int
>
> #ifdef _MT
> #  define GC_THREADS 1
> #endif
> 
> #ifdef _DEBUG
> #  define GC_DEBUG
> #endif

GC_DEBUG has no effect here since implicitly defined in test.c

> 
> #define SILENT 1
> #define __STDC__ 1

SILENT and __STDC__ has no effect.

> 
> //-DMAKE_BACK_GRAPH 
> #ifndef MAKE_BACK_GRAPH
> # define MAKE_BACK_GRAPH
> #endif //MAKE_BACK_GRAPH
> 
> //-DGC_PRINT_VERBOSE_STATS
> #ifndef GC_PRINT_VERBOSE_STATS
> # define GC_PRINT_VERBOSE_STATS
> #endif //GC_PRINT_VERBOSE_STATS
> 
> //-DDEBUG_THREADS
> #ifndef DEBUG_THREADS
> # define DEBUG_THREADS
> #endif //DEBUG_THREADS

Do MAKE_BACK_GRAPH, GC_PRINT_VERBOSE_STATS, DEBUG_THREADS matter the problem? (i.e. if you comment out these 3 definitions, would the problem go away?)

Did you try with -DGC_ASSERTIONS?

Also try with GC_DISABLE_INCREMENTAL (either macro or environment variable).

> 
> //#define SAVE_CALL_CHAIN
> //#define SAVE_CALL_COUNT 8
> ----------------------
> 
> test.c diff, as below:
> 
> -----------------------
> 
> Index: test.c
> ===================================================================
> --- test.c (revision 311)
> +++ test.c (revision 312)
> @@ -18,10 +18,16 @@
>  /* GC.  It uses GC internals to allow more precise results      */
>  /* checking for some of the tests.                              */
>  
> +#ifndef GC_THREADS
> +#  define GC_THREADS 1
> +#endif //GC_THREADS
> +
>  # ifdef HAVE_CONFIG_H
>  #   include "private/config.h"
>  # endif
>  
>  # undef GC_BUILD
>  
>  #if (defined(DBG_HDRS_ALL) || defined(MAKE_BACK_GRAPH)) && !defined(GC_DEBUG)
> ----------------------------------

BTW. It's a bit nicer to make stdafx.h empty and copy all definitions to private/config.h (and only define HAVE_CONFIG_H in test.c or in the command line (or in IDE options).

I tried to reproduce the problem (using the latest CVS) but failed (it runs ok):

I've compiled (on VS 2005 x86) the test with your options (_CRT_SECURE_NO_DEPRECATE just suppresses warnings):

cl -MT -DGC_THREADS -DMAKE_BACK_GRAPH -DGC_PRINT_VERBOSE_STATS -DDEBUG_THREADS -Iinclude -Ilibatomic_ops\src -D_CRT_SECURE_NO_DEPRECATE tests\test.c *.c user32.lib /link /stack:65536

Could you try it on your side? If it will run ok (several times), then send me (not to ML) the diff between preprocessor output (using -E option) of your version (based on the latest CVS) and mine one.

Bye.


More information about the Gc mailing list