building and debugging the Croquet VM

Hi all--

      Croquet SDK 1.0.18 crashes on one of my Windows machines when any
of the demos are started (although Qwaq Forums runs fine!). I assume the
problem is OpenGL-related; I'd like to build my own Croquet VM and debug
it. I've been debugging Squeak VMs since the first release of Squeak,
but I haven't done so on Windows since the standard C environment was
Microsoft Visual C++ (rather than gnutools, as currently cited on
squeakvm.org).

      What does one use for a C-level debugger with the Croquet VM,
given a gnutools setup? Or should I go back to MSVC++? Just switching
graphics cards (or operating systems, or motherboards) until I find one
that works isn't a viable option, unfortunately.


      thanks!

-C

p.s.

      For what it's worth, the graphics card is an NVIDIA GeForce 7600
GS, and the operating system is XP professional 32-bit. The drivers are
current and were installed after all XP updates.

Craig Latta wrote:
>      What does one use for a C-level debugger with the Croquet VM, given
> a gnutools setup? Or should I go back to MSVC++? Just switching graphics
> cards (or operating systems, or motherboards) until I find one that
> works isn't a viable option, unfortunately.

Usually, I just use printf() debugging. It's awful but it works ;-)
Alternatives may be to install cygwin and see if gdb has become usable
enough to make this a worthwhile exercise (if it has, let me know).

For the problem itself, we fixed a bunch of major issues for Qwaq Forums
(that we haven't put back yet) incl. one where we effectively assumed
that client-side state would be copied to the server (which of course,
it being *client* state, it wouldn't). Here is the relevant piece of our
code base:

        "When not using precompiled VBOs submit the geometry data right before
calling DrawElements since the pointer locations will be stored inside
the GL and mustn't be moved by the garbage collector. In fact, to be
*really* paranoid we add a guard around the following which will repeat
the code if we determine a GC whilst executing it."

        [gcCount := Smalltalk vmParameterAt: 9.
        self beginNoVBO: geometry.
        gcCount = (Smalltalk vmParameterAt: 9)] whileFalse.
        self
                glDrawElements: realMode
                with: faces basicSize
                with: GLUnsignedInt
                with: faces.

And #beginNoVBO: in the above calls glEnableClientState: and
gl[Vertex|Normal|Color]Pointer: and friends.

Cheers,
   - Andreas

Hi Andreas--

 > Usually, I just use printf() debugging. It's awful but it works ;-)
 > Alternatives may be to install cygwin and see if gdb has become usable
 > enough to make this a worthwhile exercise (if it has, let me know).

      Ah, okay, thanks.

 > For the problem itself, we fixed a bunch of major issues for Qwaq
 > Forums (that we haven't put back yet) incl. one where we effectively
 > assumed that client-side state would be copied to the server (which of
 > course, it being *client* state, it wouldn't). Here is the relevant
 > piece of our code base:
 >
 >     "When not using precompiled VBOs submit the geometry data right
 > before calling DrawElements since the pointer locations will be stored
 > inside the GL and mustn't be moved by the garbage collector. In fact,
 > to be *really* paranoid we add a guard around the following which will
 > repeat the code if we determine a GC whilst executing it."
 >
 >     [gcCount := Smalltalk vmParameterAt: 9.
 >     self beginNoVBO: geometry.
 >     gcCount = (Smalltalk vmParameterAt: 9)] whileFalse.
 >     self
 >         glDrawElements: realMode
 >         with: faces basicSize
 >         with: GLUnsignedInt
 >         with: faces.
 >
 > And #beginNoVBO: in the above calls glEnableClientState: and
 > gl[Vertex|Normal|Color]Pointer: and friends.

      Hm, is the above enough information for me to recreate a fix? :)
Or could you provide a patch?


      thanks again,

-C

Craig Latta wrote:
>      Hm, is the above enough information for me to recreate a fix? :) Or
> could you provide a patch?

I don't have the time right now to track down the paths in the SDK (our
internal code base has diverged quite a bit since the release). The main
fix in the above was actually to move the setup calls to *right before*
we call DrawElements. You might be able to find the places by looking at
the senders of glEnableClientState: and glDrawElements: and take it from
there.

Cheers,
   - Andreas

On Tue, 2007-09-18 at 15:38 -0700, Craig Latta wrote:
I had a problem with openGL and nVidia until I installed the drivers
straight from nVidia. It only took about 3-4 months to figure it out. I
hope I've saved you the pain! I've read recently that there are some
proprietary bits that have to do with openGL that are contained only in
a driver from nVidia and can be found no where else. I run linux and
every app on my machine ran just fine, every game played fast... all
except Croquet. Once I put the nVidia release driver in, I saw the
rabbit!

I just installed Fedora Core 7 and I just went through an entire pile of
upgrades to Croquet and the rabbit is dead again. So, I re-dnloaded the
Croquet install file, unpacked and installed it, and it works fine. I
re-read the docs and there it was... there is an order to updating
Croquet packages. <sigh> Gonna take it easy this time and follow the
rules. Is there an auto-updater, that follows the rules, for the user to
just click on? <grins> Ric

--
================================================
My father, Victor Moore (Vic) used to say:
"There are two Great Sins in the world...
..the Sin of Ignorance, and the Sin of Stupidity.
Only the former may be overcome." R.I.P. Dad.
Linux user# 44256 Sign up at: http://counter.li.org/
http://www.sourceforge.net/projects/oar
http://www.wayward4now.net  <---down4now too
================================================

Hi Ric--

      I'm already using the "straight from NVIDIA" driver. It doesn't help.


      thanks anyway,

-C

--
Craig Latta
improvisational musical informaticist
www.netjam.org
Smalltalkers do: [:it | All with: Class, (And love: it)]

Is the machine where croquet crashes multi-core/cpu? If yes, try to set
the cpu affinity (using the task manager) to a single core and see if it
still crashes.

rado

Hi rado--

 > Is the machine where croquet crashes multi-core/cpu? If yes, try to
 > set the cpu affinity (using the task manager) to a single core and see
 > if it still crashes.

      Interesting idea. :)  Yes, it is a multi-core machine (two), but
changing the affinity to a single core (either one) didn't change
anything. I'm pretty sure the Croquet virtual machine always ends up
running on a single core anyway.

      However, since Andreas mentioned an object movement issue, I just
tried doubling the number of allocations between incremental garbage
collections (virtual machine parameter five, set via
SystemDictionary>>vmParameterAt:put:, e.g., "Smalltalk vmParameterAt: 5
put: 8000"). I haven't had a crash since then.

      Of course, this is just a workaround, as is putting FFI calls
closer together so that there is less time for objects to move. I
suppose a more robust answer may involve some Croquet-specific
management of the C heap (annoying) or implementing immovable objects
(lots of work).

      I'm also having a go at building/debugging the VM with cygwin,
since I'm sure I'll need this soon for other things.


      thanks, everyone, for your suggestions!

-C

Craig Latta wrote:
>      However, since Andreas mentioned an object movement issue, I just
> tried doubling the number of allocations between incremental garbage
> collections (virtual machine parameter five, set via
> SystemDictionary>>vmParameterAt:put:, e.g., "Smalltalk vmParameterAt: 5
> put: 8000"). I haven't had a crash since then.

This is a pretty clear indication that it's the DrawElements bug.

Cheers,
   - Andreas

Passing pointers into the Croquet world to external processes is a a
severe no-no, and making "immovable objects" would be against
modularity, not just a lot of work.  Evil.  Don't understand why one has
to worry about the "C heap" as the only alternative.  Just copy
asynchronously read data out, and copy the results back.  This may
require a C program as a wrapper. So write the C program.

Craig Latta wrote:

On Tue, 2007-09-18 at 21:06 -0700, Craig Latta wrote:
> Hi Ric--
>
>       I'm already using the "straight from NVIDIA" driver. It doesn't help.
>
>
>       thanks anyway,

Craig,
Are you running Linux?? If so, this needs to be in your Croquet.sh file
at the very end of it:

exec "$EXE/squeak" -plugins "$EXE" \
        -vm-display-X11 -xshm -swapbtn \
        "$DIR/$IMAGE"

That "-shm" was the final cure for me. That and the nVidia driver where
all of the bells and whistles in the modules section are on.

Here's mine, which the latest offering from nVidia didn't install by
default (a known bug), in /etc/X11/xorg.conf :

Section "Module"
    Load           "dbe"
    Load           "extmod"
    Load           "fbdevhw"
    Load           "glx"
    Load           "record"
    Load           "freetype"
    Load           "type1"
EndSection

Their installer only adds "Load glx" and not the rest. It's a known bug
to be repaired

So, with all of that, you should be able to crank up Croquet. I pulled a
few hairs out getting to that point, lemme tell you! <cackles> What
doesn't kill me, makes me stronger I guess. Let me know if I can be of
further assistance. Les hangs out on this list too, and he's a
verifiable "whiz-bang" at this stuff on Linux.

Good night and Good luck! Ric
 
--
================================================
My father, Victor Moore (Vic) used to say:
"There are two Great Sins in the world...
..the Sin of Ignorance, and the Sin of Stupidity.
Only the former may be overcome." R.I.P. Dad.
Linux user# 44256 Sign up at: http://counter.li.org/
http://www.sourceforge.net/projects/oar
http://www.wayward4now.net  <---down4now too
================================================

      Wow, thanks, Ric! I'm not running Croquet on Linux yet (only
Windows and MacOS), but I'll certainly keep these tips handy in case
Linux machines enter the mix later.


      thanks again,

-C

--
Craig Latta
improvisational musical informaticist
www.netjam.org
Smalltalkers do: [:it | All with: Class, (And love: it)]