Hi,
I can build and run 32 bit Intel Linux VMs from the source and image posted in the ./dist3 directory. However, if I use recent platforms source from SVN with recent VMMaker, I get a VM that has some kind of problem apparently involving memory decoding or interpreting an instruction stream.
I can occasionally get a small image to start up with this VM (usually I get a crash related to one of the background processes or to an incremental GC at startup), but once running the image cannot accept text in a workspace, or apparently do anything else related to interpreting an instruction stream (???).
When the VM crashes, it appears to always involve one of the memory access functions (or macros as the case may be), but it happens at various times after entering the interpreter, and I have not figured anything out by looking at it under gdb.
Failures when the image is running may bring up debuggers, as shown in the attached gif. These appear to be failures interpreting a BlockContext and failures related to write stream positioning in the compiler. Presumably this is related to the memory access failures I see when the VM crashes outright.
Any ideas? Here are some artifacts of the failing VM/image:
world.3.gif is a screen dump of the minimal image after it has successfully started, with some debuggers open.
sqMemoryAccess.h is a copy of the lightly hacked file I am using, forcing use of the static inline functions rather than macros (it also includes a couple of missing macros that are not being used for purposes of these tests).
SqueakDebugLogFiles.zip contains some representative debug log files that may give some clues as to what is going wrong.
I must be looking past something obvious, but I can't spot it.
Dave
I can't see it either. Diffing your version of sqMemoryAccess and mine shows no functional difference I can see. A couple of things in different order, a couple of duplicated defines moved out so they don't need to be duplicated, a couple of extra macros that I hadn't found a need for.
I don't suppose putting those things in slightly different order can confuse that wonderful compiler? Surely not... Does it work if you use the macros instead of the inline statics? It works( worked, anyway) both ways on RISC OS and OSX a while back.
tim -- Tim Rowledge, tim@rowledge.org, http://www.rowledge.org/tim All wiyht. Rho sritched mg kegtops awound?
Trying a different compiler might help - I've seen similar effects with later gcc versions when trying to compile a 64bit VM.
Cheers, - Andreas
Tim Rowledge wrote:
I can't see it either. Diffing your version of sqMemoryAccess and mine shows no functional difference I can see. A couple of things in different order, a couple of duplicated defines moved out so they don't need to be duplicated, a couple of extra macros that I hadn't found a need for.
I don't suppose putting those things in slightly different order can confuse that wonderful compiler? Surely not... Does it work if you use the macros instead of the inline statics? It works( worked, anyway) both ways on RISC OS and OSX a while back.
tim
Tim Rowledge, tim@rowledge.org, http://www.rowledge.org/tim All wiyht. Rho sritched mg kegtops awound?
On Fri, Jul 08, 2005 at 08:42:17PM +0200, Andreas Raab wrote:
Trying a different compiler might help - I've seen similar effects with later gcc versions when trying to compile a 64bit VM.
Thanks. I have a copy of egcs-2.91.66 installed on a dusty old Linux box. I'll give it a try and see if it acts any differently from the gcc 3.3.1 I've been using.
Dave
On Fri, Jul 08, 2005 at 04:26:44PM -0400, David T. Lewis wrote:
On Fri, Jul 08, 2005 at 08:42:17PM +0200, Andreas Raab wrote:
Trying a different compiler might help - I've seen similar effects with later gcc versions when trying to compile a 64bit VM.
Thanks. I have a copy of egcs-2.91.66 installed on a dusty old Linux box. I'll give it a try and see if it acts any differently from the gcc 3.3.1 I've been using.
Changing compiler versions did change the behavior of the VM. With a VM compiled with egcs-2.91.66 (rather than gcc 3.3.1), I get consistent VM crashes when trying to start the small image. The crashes happen a little differently than with the VM built with gcc 3.3.1, but it seems to to be related to the same underlying problem (whatever that may be).
I am reluctant to draw any conclusions from this, because the crashes happen after entering interpret(), and seem to be timing dependent and possibly related to what Smalltalk process happens to be scheduled at what time when the image is being restarted.
Overall I think there must be some other underlying problem that I have not spotted, although the different behavior with different compilers is admittedly rather suspiscious.
For reference, the SqueakDebug.log files that I get when my image crashes on the egcs-2.91.66 VM look like this:
----------------------------- Unwind error during termination 8 July 2005 5:36:44 pm
VM: unix - a SmalltalkImage Image: Squeak3.8gamma [latest update: #6548]
SecurityManager state: Restricted: false FileAccess: true SocketAccess: true Working Dir /tmp/sq/Squeak64BitPort/images Trusted Dir /tmp/sq/Squeak64BitPort/images Untrusted Dir /tmp/sq/Squeak64BitPort/images
Association(Object)>>doesNotUnderstand: #cannotReturn:to: -----------------------------
This looks like a ContextPart>>cannotReturn:to: that got sent to the wrong object, possibly due to scrambled interpretation of the layout of a BlockContext. This is consistent with the kind of error I see with the VM compiled with the other gcc version; it just seems to be manifesting itself at a different time and place in the interpreter.
Dave
On Fri, Jul 08, 2005 at 11:32:06AM -0700, Tim Rowledge wrote:
I can't see it either. Diffing your version of sqMemoryAccess and mine shows no functional difference I can see. A couple of things in different order, a couple of duplicated defines moved out so they don't need to be duplicated, a couple of extra macros that I hadn't found a need for.
I don't suppose putting those things in slightly different order can confuse that wonderful compiler? Surely not... Does it work if you use the macros instead of the inline statics? It works( worked, anyway) both ways on RISC OS and OSX a while back.
I get similar results whether I am using the macros or the static inline functions, and the latter have not changed since the dist3 source code. I just attached my sqMemoryAccess.h in the interest of full disclosure, but I don't think that it is causing the problem.
I've diffed through all the ./platforms source to compare current SVN source to the older dist3 source, and I don't see anything that looks wrong. Likewise, I don't see anything different in VMMaker that looks like a problem. There are quite a few changes to the unix configure script, so maybe there's something hidden in there that has an effect. I just can't spot it, whatever it is.
I'm using gcc 3.3.1, which is not what Ian recommends, but I would not expect that to be an issue given that it worked fine for me on the older code.
Still stumped,
Dave
vm-dev@lists.squeakfoundation.org
-
Andreas Raab -
David T. Lewis -
Tim Rowledge