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