[M3devel] threading on Windows?

[Tony Hosking]

Looks like stack overflow to me.

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On Feb 12, 2011, at 9:09 AM, Jay K wrote:

> > >LINUXLIBC6 : seg fault
> 
> I've seen this now.
> 
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0xb3200b90 (LWP 18154)]
> 0xb6dee58f in RTCollector__Move (self=0xb6a9000c, cp=0xb6a20014)
>     at ../src/runtime/common/RTCollector.m3:409
> 409        IF hdr.typecode = RT0.TextLitTypecode THEN RETURN END;
> 1: x/i $pc
> 0xb6dee58f <RTCollector__Move+83>:    mov    (%eax),%eax
> (gdb) bt 9
> #0  0xb6dee58f in RTCollector__Move (self=0xb6a9000c, cp=0xb6a20014)
>     at ../src/runtime/common/RTCollector.m3:409
> #1  0xb6deaa46 in RTHeapMap__Walk (x=0xb6a20014, pc=0xb7738648, v=0xb6a9000c)
>     at ../src/runtime/common/RTHeapMap.m3:202
> #2  0xb6dea341 in RTHeapMap__DoWalkRef (t=0xb7738694, a=0xb6a20014, 
>     v=0xb6a9000c) at ../src/runtime/common/RTHeapMap.m3:62
> #3  0xb6dea318 in RTHeapMap__DoWalkRef (t=0xb7739c54, a=0xb6a2000c, 
>     v=0xb6a9000c) at ../src/runtime/common/RTHeapMap.m3:57
> #4  0xb6dea318 in RTHeapMap__DoWalkRef (t=0xb7739e68, a=0xb6a2000c, 
>     v=0xb6a9000c) at ../src/runtime/common/RTHeapMap.m3:57
> #5  0xb6dea2bf in RTHeapMap__WalkRef (h=0xb6a20008, v=0xb6a9000c)
>     at ../src/runtime/common/RTHeapMap.m3:47
> #6  0xb6df0636 in RTCollector__CleanBetween (h=0xb6a20008, he=0xb6a30000, 
>     clean=0 '\0') at ../src/runtime/common/RTCollector.m3:1091
> #7  0xb6df0473 in RTCollector__CleanPage (page=0xb6a20000)
>     at ../src/runtime/common/RTCollector.m3:1064
> #8  0xb6defc96 in RTCollector__CollectSomeInStateZero ()
>     at ../src/runtime/common/RTCollector.m3:885
> (More stack frames follow...)
> (gdb) p $eax
> $2 = 2097148
> (gdb) p/x $eax
> $3 = 0x1ffffc
> (gdb) x/x $eax+4
> 0x200000:    Cannot access memory at address 0x200000
> (gdb) x/x $eax
> 0x1ffffc:    Cannot access memory at address 0x1ffffc
> 
> 
> Maybe I should try with a correctly sized jmpbuf to assure it isn't stack overflow?
> But notice that the next page doesn't work either. Actually I tried adding
> a lot to $eax and still not accessible.
> 
> 
> Maybe maybe maybe maybe I'll dig into this. But I'm very busy lately and maybe indefinitely into future..
> 
> 
> Thanks,
>  - Jay
> 
> 
> > To: jay.krell at cornell.edu; hosking at cs.purdue.edu
> > Date: Fri, 11 Feb 2011 22:48:12 -0800
> > From: mika at async.caltech.edu
> > CC: m3devel at elegosoft.com
> > Subject: Re: [M3devel] threading on Windows?
> > 
> > Well, with the following changes: re-bootstrapping on the two Linux
> > systems and removal of the -pthread flag on FreeBSD4, all is well.
> > User threading works on all the architectures listed below, at least
> > as far as the thread testing program can test it. (It seems that because
> > of the way pthread_atfork is coded, pthread is not needed at all on
> > FreeBSD4.)
> > 
> > Mika
> > 
> > Mika Nystrom writes:
> > >Another odd datapoint is that even rather aggressive testing seems not
> > >to have any trouble on I386_DARWIN (same as AMD64_FREEBSD). With user
> > >threads, of course.
> > >
> > >So status right now of user threads seems to be:
> > >
> > >FreeBSD4 : strange failure in libpthread as reported by gdb
> > >LINUXLIBC6 : seg fault
> > >AMD64_LINUX : seg fault
> > >AMD64_FREEBSD : OK
> > >I386_DARWIN : OK

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110213/4a7db00c/attachment-0002.html>