[M3devel] p007 not terminating on NT386

[Tony Hosking]

On 1 Sep 2009, at 10:13, Jay K wrote:

>
> AutoFlushWr:
>  on non-I386_OPENBSD, it passed in the test runs, but generally hit  
> assertion failures in manual runs -- on LINUXLIBC6, NT386, and maybe  
> others.
>  on I386_OPENBSD: it hangs
>
>
>  The code was a bit hard for me to verify the correctness of. I  
> replaced it with an easy to understand version and the non- 
> I386_OPENBSD problems went away. The I386_OPENBSD hang remains.
>
>
> In particular, AutoFlushWr layers a Wr over a Wr, but if the  
> underlying Wr is buffered, it strives to not add an additional  
> buffering layer. If the underlying Wr is not buffered, it does add  
> buffering. All Wrs have a few public fields to implement buffering.  
> AutoFlushWr copies these fields back and forth. I think it was a)  
> optimizing which fields to copy based on knowing which fields the  
> toplevel Wr modified when b) I think it was doing some computation  
> them that it should not have, instead of just copying them. I just  
> have it basically copy all the fields all the time. There are just a  
> few.

OK, sounds like we all need to take a closer look at this code and  
satisfy ourselves that it is now correct.

> Agreed, the I386_OPENBSD hang might be related.
> I think I might have to try out very old versions, like I'm doing  
> (slowly!) for the formsedit crash.
> Maybe not, since the I386_OPENBSD hang is easy to reproduce and only  
> involves two threads -- not too complicated.

This is particularly weird, since it is clear that the main thread is  
trying to stop the other thread, but the other thread is not  
responding.  I wonder if signal delivery to waiting threads is broken  
on OpenBSD?

> I think p007 also hangs on Cygwin, but it always has. I tried  
> debugging it but Cygwin seemed like a mess. Granted, it hung with  
> Cygwin whether or not I used pthreads or NT threads.

I have a feeling p007 is just buggy in itself -- it looks like there  
is a serious race in there.  So, in this case I think the test is  
broken, not the platform.  I'll try to clean it up.


> Recentness isn't particularly clear I think, since I don't think  
> these platforms have ever had good test coverage. But I did think  
> regular NT386 was ok here.
>
>
> Later,
> - Jay
>
>
> ________________________________
>> From: hosking at cs.purdue.edu
>> To: wagner at elegosoft.com
>> Date: Tue, 1 Sep 2009 09:51:23 -0400
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] p007 not terminating on NT386
>>
>> These thread problems are relatively new (similar to Jay's problems  
>> with AutoFlushWr...). Something quite bad must have happened  
>> recently to cause them. I took a quick look at ThreadPThread.m3 but  
>> didn't notice anything obviously wrong. Something else perhaps?
>>
>> 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 1 Sep 2009, at 08:56, Olaf Wagner wrote:
>>
>> It looks as if m3test p007 does not terminate any more on NT386.
>> This used to work. I just found this
>>
>> --- p007 --- a whole bunch of threads - does the memory grow ?
>>
>> cd ..\src\p0\p007 && cm3 -silent -DM3TESTS>NT386\stdout.build.raw  
>> 2>NT386\stderr.build.raw
>>
>> running for more than 5 hours.
>>
>> The last successful run was
>> http://hudson.modula3.com:8080/view/NT386/job/cm3-test-m3tests-NT386/212/ 
>> .
>>
>> Olaf
>> --
>> Olaf Wagner -- elego Software Solutions GmbH
>> Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany
>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23  
>> 45 86 95
>> http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz:  
>> Berlin
>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr:  
>> DE163214194
>>
>>