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

Ivan Maidanski ivmai at
Thu Nov 5 06:14:12 PST 2009

Zeyi Lee <biosli at> wrote:
> Hi,
> > > > > > > I got a Data Abort as below:
> ...
> > 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).
> It seems odd that the Data Abort does not occur every time today.
> I test 10 times at least, only occurs twice.
> I will do further test as you said.
> > > > Could you tell me the moment from which Data Abort began to occur?
> > >
> > > It's hard to make breakpoints for the Data Abort. But I will try.
> > 
> > I meant not from which moment from test start, I meant from which CVS version you observe Data Aborts. (I remember you observe it a month or two ago but this was solved.)
> I will find that version...

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).

> > > > It seems that an entry (0xad0) in GC_threads is replaced with a duplicate entry 0xad4 at some place. Could you debug GC_new_thread() and see the place which breaks GC_threads[]?
> > >
> > > I found that:
> > > There are two cases make the "Collecting from unknown thread" DebugBreak.
> > >
> > > Case 1:
> > > There are same thread ID in GC_threads. I send log in my last letter.
> > >
> The case occurs after log print : ***>Full mark for collection 3 after 97928 allocd bytes
> At that time, create new threads made GC_threads data error.(the new thread add to the GC_threads in new slot and covered old slot in GC_threads. so there is thread in two slots of GC_threads, and old one lost..., then "Collecting from unknown thread".)
> > > Case 2:
> > > When I debug step by step, I find GC_thread remove the thread in use.
> > > I send the log in this case as the attachment.
> > 
> > Send me a backtrace (where a thread is removed from GC_thread or where a duplicate is added).
> There is a backtrace pic and a log print for you(in attachment).
> The function GC_reclaim_clear remove the using thread in GC_threads.
> pls, check the log for detail. 
> I print
> "-----------------------------backtrack pic print here-----------------------------"
> for it in log.
> Bye.
> Windows 7

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;
- full list of parameters you compiled and linked test.c with (including the contents of stdafx.h if you still use it).


More information about the Gc mailing list