Re: [Gc]: GC + Windows Mobile + Threads + Patch for WINCE
ivmai at mail.ru
Fri Nov 6 03:45:55 PST 2009
Zeyi Lee <biosli at hotmail.com> wrote:
> > > > 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
> #ifdef _DEBUG
> # define GC_DEBUG
GC_DEBUG has no effect here since implicitly defined in test.c
> #define SILENT 1
> #define __STDC__ 1
SILENT and __STDC__ has no effect.
> #ifndef MAKE_BACK_GRAPH
> # define MAKE_BACK_GRAPH
> #endif //MAKE_BACK_GRAPH
> #ifndef GC_PRINT_VERBOSE_STATS
> # define GC_PRINT_VERBOSE_STATS
> #endif //GC_PRINT_VERBOSE_STATS
> #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.
More information about the Gc