Problem building from latest SNV & VMM

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, [hidden email], 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:

On Fri, Jul 08, 2005 at 11:32:06AM -0700, Tim Rowledge wrote:
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

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