[Sbcl-devel] Windows shortcut & startup mystery, any ideas?

[Nikodemus S. <nik...@ra...>]

There is something very wierd going on with SBCL startup, esp. via
shortcuts.

To observe:

1. build SBCL on Windows, build the installer, install.

2. Start SBCL from the shortcut installed to the program menu / all
   programs. Enter (loop (compile nil '(lambda ()))), and observe
   SBCL going berserk. Hit C-c.

3. Right click on the same shortcut, select "send to desktop".

4. Start SBCL using the shortcut now on desktop, observe it immediately
   crashing and burning its way down to LDB.

3. Right click on the original shortcut, select "attach to startup
   menu", what ever the text really says in your (un)localized
   installation.

4. Start SBCL from the start menu (the new shortcut, apparently identical
   the one in All Programs). Enter (loop (compile nil '(lambda ()))),
   and observe SBCL spinning happily till you C-c it to oblivion.

The extent I've been able to verify, once put to the main Start Menu,
or "Oftern Used Programs" the shortcut works perfectly. Starting SBCL
from the command line also seems to work fine.

Add --debug-environment to the shortcut command lines, and you will be
able to verify that the command line arguments and environment are
indeed identical.

The only difference (aside from non-workingness, that is) is that in
the SBCL started directly from that shortcut in All Programs ROOM
reports subtly different from what the working one started from main
Start Menu. To wit, the working one has two conses too little, and
words of memory too many in "other objects".

NON-WORKING
Breakdown for dynamic space:
   9,362,920 bytes for     9,912 code objects.
   3,097,112 bytes for    72,108 instance objects.
   3,013,368 bytes for   376,671 cons objects.
   2,891,848 bytes for    41,519 simple-vector objects.
   5,072,432 bytes for   130,254 other objects.
  23,437,680 bytes for   630,464 dynamic objects (space total.)

WORKING
Breakdown for dynamic space:
   9,362,920 bytes for     9,912 code objects.
   3,097,112 bytes for    72,108 instance objects.
   3,013,384 bytes for   376,673 cons objects.
   2,891,848 bytes for    41,519 simple-vector objects.
   5,072,416 bytes for   130,254 other objects.
  23,437,680 bytes for   630,466 dynamic objects (space total.)

So something is corrupting the heap under (at least on my setup)
easily reproducible conditions, but I have really no idea what, or how
to best debug this.

Any ideas? Does someone know how the execution of programs from these
different contexts differs? Places where eg. exception handling might
corrupt at tag or two?

Cheers,

  -- Nikodemus              Schemer: "Buddha is small, clean, and serious."
                   Lispnik: "Buddha is big, has hairy armpits, and laughs."