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

Ivan Maidanski ivmai at mail.ru
Mon Nov 2 00:47:42 PST 2009


Zeyi Lee <biosli at hotmail.com> wrote:
> Hi
>
> > Zeyi Lee <biosli at hotmail.com> wrote:
> > > Hi,
> > > Ivan Maidanski <ivmai at ...> writes:
> > > > >
> > > > > I test the version with several case on my WINCE box, as following:
> > > > > Case 1:
> > > > > -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
> > > > >
> > > > > I got a Data Abort as below:
> > > > > -------------------
> > > > > Data Abort: Thread=8efce000 Proc=8c398520 'test_libgcd_Wince.exe'
> > > > > AKY=00040001 PC=0001a9d4(test_libgcd_Wince.exe+0x0000a9d4)
> > > > RA=0001a1e4(test_libgcd_Wince.exe+0x0000a1e4) BVA=2787fc0c FSR=00000007
> > > > > -------------------
> > > > > Then the program runs to the end.
> > > > > ...
> > > > > Collector appears to work
> > > > > ------------------------
> > > >
> > > > The situation is unclear to me.
> > > >
> > > > 1. Could you tell me the backtrace?
> > >
> > > There is no DebugBreak and I don't know where makes the Data Abort.
> >
> > I don't know neither. Try to set a breakpoint at that PC value (this may be not the same backtrace as which results in data abort but...
> >
> > >
> > > > 3. Does Data Abort also occur without -DMAKE_BACK_GRAPH?
> > > Yes, without -DMAKE_BACK_GRAPH the Data Abort also occurs.
> >
> > So, in your project (with your options) Data Abort also occurs, right?
> > What are the options? (Announce the full list, please.)
>
> It test on my winCE PPC.
>
> And options are:
>
> -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

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

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

> > Still unclear...
> >
> > The log in brief:
> >
> > About to create a thread from 0xa50
> >
> > ....................
> >
> > 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.
>
> 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).

> I will do further test.

Bye.


More information about the Gc mailing list