[M3devel] more info on juno on windows

[Jay K]

Again, what I see is that many versions before around Feb 20 2007 consistently fail with that same assertion failure.

I have tested many versions now, recently.

But versions after Feb 20 2007 usually access violate on the address 0x20000 or so, sometimes other addresses, sometimes various assertion failures. I believe this is much worse than merely always failing the same assertion.

 

 - Jay
 


Date: Tue, 22 Sep 2009 17:06:20 -0400
From: rcoleburn at scires.com
To: m3devel at elegosoft.com
Subject: [M3devel] more info on juno on windows




Do we know whether or not Juno ever worked on Windows ?
 
I don't recall ever testing it on Windows.  I still have a vd5.7.0 cm3 that I used for the project I finished up last year (August 2008).  If I run Juno on this system (Windows XP SP3), Juno crashes with an ASSERT failure at line 165 in winvbt/WinContext.m3.  The date on the juno.exe is 8/19/2008.
 
Regards,
Randy

>>> Jay K <jay.krell at cornell.edu> 9/22/2009 2:57 PM >>>
Here is the truncated part from the previous:
 
This change, I think, causes Juno to access violate whereas before it "only" failed assertions.
I believe it is considered fairly ok for a safe system to terminate with an assertion failure,
that might not be a bug at all, but considered far worse to hit a SIGSEGV.

formsedit crashes usually on Solaris.

Maybe other platforms. I still have to retry PPC_DARWIN. (and others?)
It seems to date to right around 1/23/2007, changing from userthreads to pthreads.
Again I checked out and built the tree at various dates, I got it to within a very
small window, like 1/20/2007 - 1/25/2007.
I haven't tried toggling pthreads on/off in head..well..I did for other reasons.
userthreads I think are broken, initialization order.
 

Can anyone confirm these problems exist?
 
and new content:
  I don't like to speculate if there are problems, and if only one person sees them (even if it is me), that is close to speculation. It is good to get independent verification.
  You shouldn't need to test your specific code. Just run Juno under a debugger a few times and see if it access violates. Assertion failures I think are ok, unless they are asserting e.g. foo != NIL on the line before derefencing foo (as formsedit now does).

 - Jay
 




From: jay.krell at cornell.edu
To: rcoleburn at scires.com; m3devel at elegosoft.com
Subject: RE: [M3devel] CM3 5.8 Release Engineering, was Re: back again -- cm3 status worse?
Date: Tue, 22 Sep 2009 18:52:37 +0000



 > specifically referencing a particular set of Modula-3 code that was done poorly

Correct, and it can't be fixed in Modula-3.
Specifically m3-libs/m3core/src/unix/*.i3, and some other code like it (potentially X, OpenGL, Win32).
Specifically *.i3 files that duplicate C *.h files, esp. hard to read platform-specific *.h files.
The goal is not to rewrite everything in C.
The goal is where we call into C, that we did not write, to have a C layer that we control and can easily read.
At least where the underlying C is #ifdefed into unreadability or platform-specific.
You should be able to read the m3core source without access to /usr/include of every system and have some confidence of its correctness. Previously you needed access to every target platform's /usr/include to verify it.
 
 
I don't know if the problem is with the garbage collector or threads or Juno or gui stuff.
I did look at the thread stuff some. They were seemingly small changes.
 I also tried going back just one version to before redoing part of the change. That also crashed.
I looked at the gc changes, I don't understand them all. Some, but not all.
I'm going to back to the Feb 20 version and see if I can tease apart some of it and find out when it starts failing.
And confirm that source before/after that time succeeds/fails.
 
 - Jay

 




Date: Tue, 22 Sep 2009 10:00:05 -0400
From: rcoleburn at scires.com
To: m3devel at elegosoft.com
Subject: Re: [M3devel] CM3 5.8 Release Engineering, was Re: back again -- cm3 status worse?


Jay your message seems truncated again.
 
Threads have always worked for me in the past on Windows.  Do we have some sort of tests we can run to prove correctness of threading?  Seems to me that Juno is the only thing that isn't working right, supposedly wrt threading.  Perhaps the problem lies in Juno and not threads.  Maybe Juno is misusing threads in some way or there is a bug in something Juno uses that exhibits itself as a thread problem.  Granted, the last time I did heavy checks on my multithreaded code on Windows was before the date you say a problem was introduced, so maybe it is broken now.  In any event, I think some standard regression type tests would be in order here.  If we don't have them, perhaps Tony could offer some suggestions.  I would be glad to write some of these tests if given some general ideas on what to check for.
 
I don't want to get into a big argument with you (or anyone else), but I do take exception with your statements about Modula-3 being "tedious, error prone, unsafe, not portable, target-specific."  Perhaps I am misinterpreting you here and you are specifically referencing a particular set of Modula-3 code that was done poorly.  If so, then perhaps if you could explain what is wrong with the Modula-3 code in question, one of us can step up to the plate and make some corrections.  If the SPIN folks could write an OS in Modula-3, surely we can write the compiler and library code in Modula-3.  IMO, writing such code in Modula-3 should give us the benefits of Modula-3 instead of the deficiencies of C.  After all, this mail list is for Modula-3 enthusiasts.  We wouldn't be spending time if we didn't think this language was great.
 
Regards,
Randy

>>> Jay K <jay.krell at cornell.edu> 9/22/2009 8:16 AM >>>

The problem with the Modula-3 code is the same as usual.
It is tedious, error prone, unsafe, not portable, target-specific.
Specifically Utime.i3/Usysdep.i3/DateBsd.m3/DatePosix.m3.
The other -- TimePosix.m3, probably ok.

Not tremendously so in this case, just a little.

The idea is to drive Usysdep.i3 to empty, but the last bits might not be worth it.




The C layer is also tedious and error-prone, and maybe unsafe,
  but it is portable and target-independent, which reduces
  but tedium and error-proneness.




Look at the Utime.i3 cloning/extension in the Modula-3 web browsers.
They actually get it wrong on some systems (Cygwin, Solaris, HP-UX) and
the result is that the safety guaranteeds are broken.




C code wouldn't have this problem. It would #include <time.h> and fail to compile.





Yes there is fairly definitely a problem on Windows and it dates, I think, to this change:





2009-02-16 02:20  hosking

  * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/dtoa.c,
    Csupport/little-endian/dtoa.c, convert/CConvert.i3,
    convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3,
    runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3,
    runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3,
    thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3,
    thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ThreadPThreadC.i3,
    thread/WIN32/ThreadWin32.m3:

  Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better match underlying pthread semantics.
  This means that RTOS.WaitHeap must be called while RTOS.LockHeap is held.
  RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or not.





I'll have to reconfirm that I guess.
I had checked out and built the CVS tree at many dates/times, doing roughly
binary search, and narrowed it down to this.

Though Tony has undone this change.

I admit 1) I haven't really looked at the diffs either way and 2) I don't really understand the ThreadPThread.m3 and ThreadWin32.m3 code very well.



???It might be worthwhile to try to rewrite ThreadWin32.m3 from scratch, following ThreadPThread.m3 line for line and coming up with analogs? Along with the unscalable replacement for condition variables -- taking one global lock around certain things to get atomiticy? (Search the web for how to implement condition variables on Win32, you start to get an idea, though Modula-3 doesn't take anyone else's approach..you see all the literature is very concerned with the atomicity of certain runs of operations, that you can get on NT4 and newer at the cost of kernel transitions (SignalObjectAndWait?) but that Modula-3 gets by using a "giant lock" in some places, which might be better, might be worse).

It also might be worthwhile reimplementing for Vista or newer, verify it at least works, even if the pre-Vista code remains supported for pre-Vista. (Vista adds condition variables.)

You know, if that succeeds, it pins the blame on ThreadWin32.m3.

If it also fails, it leaves it ambiguous as to if both "ThreadWin32CV.m3" (not yet existant) are bad, or if the problem is elsewhere.




It /seems/ that Juno's pixmaps are getting copied over other data.




This change, I think, causes Juno to access violate whereas before it "only" failed assertions.

I believe it is considered fairly ok for a safe system to terminate with an assertion failure,
that might not be a bug at all, but considered far worse to hit a SIGSEGV 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20090922/93e7679e/attachment-0002.html>