Deployment problem

I'm trying to use the Lagoon Deployment Wizard. I'm getting an error at
the very end which I can't seem to get around, and I'm sure it's
because I have an incorrect option set. Just hoping someone could give
me a quick hint.

---------------------------
Dolphin Smalltalk X6 Professional
---------------------------
The following error occurred while stripping.

The image MUST exit immediately, but see crash dump (if configured).



SDWORDField class does not understand #alignment
---------------------------
OK
---------------------------

Obviously SDWORDField does understand #alignment, so I'm assuming the
stripper is removing it for some unknown reason. Any ideas?

Thanks!

Jeff M.

Hi Jeff M.,

> I'm trying to use the Lagoon Deployment Wizard. I'm getting an error
> at the very end which I can't seem to get around, and I'm sure it's
> because I have an incorrect option set. Just hoping someone could give
> me a quick hint.

Try doing your deployment from a clean image that you load your stuff into
(and try to limit the use of development tools) was one hint that was given
to me - it might work in your case.

The next is to try using the special dont strip category (but I can't remember
the exact spelling of it - sorry).

The others probably have more help for you - but there's some basics to get
you started.

Tim

Jeff,

 
> > I'm trying to use the Lagoon Deployment Wizard. I'm getting an error
> > at the very end which I can't seem to get around, and I'm sure it's
> > because I have an incorrect option set. Just hoping someone could
> > give me a quick hint.
>
> Try doing your deployment from a clean image that you load your stuff
> into (and try to limit the use of development tools) was one hint
> that was given to me - it might work in your case.

Try what Tim suggests (i.e. using a fresh image immediately before a
deploy) as that is always the first recourse when a deployment fails.

However, as it happens (SDWORDField class) DOESN'T understand alignment
so I don't think it's just a case of the stripper removing too much
since it should never be sent in the first place. Just as a test, try
turning off (or on) the Compile External Structures option in Step 5 of
the Lagoon Wizard.

If you can post/e-mail the dump file that results that would be most
helpful. Since the dump can be quite large and might contain previous
errors, make sure to delete it first before running your failing
deployment again.

--
Best regards,

Andy Bower
Dolphin Support
www.object-arts.com

Jeff,

> SDWORDField class does not understand #alignment
> ---------------------------
> OK
> ---------------------------
>
> Obviously SDWORDField does understand #alignment, so I'm assuming the
> stripper is removing it for some unknown reason. Any ideas?

You might also look at senders of #alignment and why they might be
needed during stripping.  My guess is that something is trying to
compile a structure definition or otherwise access structure fields; it
might be as simple as doing some prodding of the struct before stripping.

Have a good one,

Bill


--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Andy Bower wrote:
Tried to no avail. :-(


> However, as it happens (SDWORDField class) DOESN'T understand alignment
> so I don't think it's just a case of the stripper removing too much
> since it should never be sent in the first place. Just as a test, try
> turning off (or on) the Compile External Structures option in Step 5 of
> the Lagoon Wizard.

Ditto results. Both on and off.


> If you can post/e-mail the dump file that results that would be most
> helpful. Since the dump can be quite large and might contain previous
> errors, make sure to delete it first before running your failing
> deployment again.

I assume you mean the EXE that is generated (or at least 1/2
generated). I can do this. Out of curiosity, what do you hope to get
from it?

Jeff M.

Jeff,

>I assume you mean the EXE that is generated (or at least 1/2
>generated). I can do this. Out of curiosity, what do you hope to get
>from it?

I think Andy is talking about the log file generated by the deployment
process.  

When you use the deployment wizard you will see, on the step 2, a
couple of check boxes - on to turn logging on and one to log class
references.  

If you turn both on and deploy then you should find that an xml file,
with the same name as your app, has been created in the target folder.

This file will contain information, a lot of information, about the
deployment - showing what was removed, what was retained and the
sequence in which it occurred.  It can be used to work out, or at
least get a better idea,  why the deployment is failing.
--
Ian

The From address is valid - for the moment

>I think Andy is talking about the log file generated by the deployment
>process.  

ummm, or maybe not.  Reading it again I think he's probably talking
about the error file created by Dolphin when it encounters an error.

I'll go away now :-)
--
Ian

The From address is valid - for the moment

For anyone interested, this was entirely my own fault. I had this:

    defineField: #Pitch type: SDWORDField offset: 0;

Instead of:

    defineField: #Pitch type: SDWORDField new offset: 0;

Thanks to Andy for pointing me in the right direction. Now I just need
to figure out how to read the .ERRORS file myself so these things
become more obvious.

Jeff M.

"Jeff M." <[hidden email]> wrote in message
news:[hidden email]...
Jeff

Issues like this with typos, alignment errors, and other human errors, are
one of the main reasons we no longer write these structure definitions,
constant declarations, and COM interface definitions by hand. The other
reason is that it is bloody tedious :-).

These days we almost always use a type library from which we use the AX
Component Wizard to generate the definitions. If there is no type library
available, we build one from the IDL using MIDL (which is part of the freely
downloadable Windows Platform SDK). If there is no IDL, we construct it from
the .h files, which is usually relatively easy given a little knowledge of
IDL and a few editor macros. You may be lucky and find that someone has
already done this work for you in order to use an API easily from an
environment such as VB6. We started our own Win32 type library from one
such. However you need to be a bit careful with these, as sometimes the
definitions are altered to suit the limitations of the language; for example
VB doesn't (or didn't) support unsigned types, so these are often changed
(rather dubiously) to signed integers.

At some point we re-generated most of the hand-coded structures in the base
Dolphin image using this technique, and found a number of errors that we
were not aware of such as missing fields, wrong types, and incorrect
alignment. Getting these things right is very important, because if the
structure size is too small then you are at risk of having the external code
write off the end of the object which will typically damage the running
system in ways that are not recoverable. The only surer way of bringing the
system down is to get the parameters to an external call (or callback) wrong
such that a stack fault results.

Regards

OA

Jeff,

Just to help you figure this out let's look at how to read a .ERRORS
file. Here's the top of your file:

---
************************************************************************
************************** Dolphin Crash Dump Report
***************************

13:28:39 PM, 9/12/2006: Dolphin.exe caused an unhandled Win32 Exception
20000002
at 7C812A5B in module 7C800000 (C:\WINDOWS\system32\kernel32.dll)

*----> Exception Parameters <----*
027CCAB8 SDWORDField class does not understand #a

*----> CPU Context for thread 0x10dc <----*
EAX = 00C0FD60 EBX = 0A790300 ECX = 00000000
ESI = 0ADD22F4 EDI = FFFFFFFF EIP = 7C812A5B
ESP = 00C0FD5C EBP = 00C0FDB0 EFL = 00000202
CS = 001B SS = 0023 DS = 0023
ES = 0023 FS = 003B GS = 0000

*----> VM Context <----*
Process: {0AE60004:size 392 words, suspended frame 0AE6060D, priority
5, callbacks 0
last failure 0:nil, FPE mask 3, thread 1161172}
Active Method: VMLibrary>>crashDump:
IP: 0A7981AA (18)
SP: 0AE605EC
BP: 0AE605BC (351)
ActiveFrame: {0AE605C4: cf 0AE605A1, sp 00000000, bp 0AE605BC, ip 0,
VMLibrary>>crashDump:}
        receiver: a VMLibrary
        arg[0]: 'SDWORDField class does not understand #alignment'
        stack temp[0]: a ByteArray


New Method:
KernelLibrary>>raiseException:dwExceptionFlags:nNumberOfArguments:lpArgu
ments:
Message Selector:
raiseException:dwExceptionFlags:nNumberOfArguments:lpArguments:
---

There's not much of use here except a print of the error that caused
the dump. In this case: "SDWORDField class does not understand
#alignment". What we are really interested in is the stack backtrace
that follows.

In the backtrace the top of the stack (i.e the most recent method
invocation is printed first). I usually work from both ends of the
trace to zoom in on the bit that is actually failing. In your trace you
have at the top:

--
*----> Stack Back Trace <----*
{0AE605C4: cf 0AE605A1, sp 00000000, bp 0AE605BC, ip 0,
VMLibrary>>crashDump:}
        receiver: a VMLibrary
        arg[0]: 'SDWORDField class does not understand #alignment'
        stack temp[0]: a ByteArray

{0AE605A0: cf 0AE6057D, sp 0AE605B4, bp 0AE60598, ip 28,
ImageStripper>>onError:}
        receiver: a ImageStripper
        arg[0]: a MessageNotUnderstood
        stack temp[0]: 'The following error occurred while stripping.
\0D\\0A\The image MUST exit immediately,...'

{0AE6057C: cf 0AE6055D, sp 0AE60590, bp 0AE60578, ip 251, [] in
ImageStripper>>stripAndSaveNotifying:}
        receiver: a ImageStripper
        arg[0]: a MessageNotUnderstood
--

Each frame is a different method call along with the parameters passed
to it. As a "user" I don't really recognize anything here because these
methods are all to do with the error handling code itself. Keeping
going down and eventually I see:

--
{0AE60440: cf 0AE6041D, sp 0AE60454, bp 0AE60438, ip 12,
MessageNotUnderstood class>>receiver:message:}
        receiver: MessageNotUnderstood
        arg[0]: SDWORDField
        arg[1]: Message selector: alignment arguments: ***Bad Array: 00000000

{0AE6041C: cf 0AE603F9, sp 0AE60430, bp 0AE60418, ip 4, SDWORDField
class(Object)>>doesNotUnderstand:}
        receiver: SDWORDField
        arg[0]: Message selector: alignment arguments: ***Bad Array: 00000000

{0AE603F8: cf 0AE603CD, sp 0AE60410, bp 0AE603EC, ip 10, D3DLOCKED_RECT
class(ExternalStructure class)>>defineField:type:offset:}
        receiver: D3DLOCKED_RECT
        arg[0]: Pitch
        arg[1]: SDWORDField
        arg[2]: 0
--

So here a see the original call that generates the "x does not
understand y" error message. This is a call of #receiver:message: being
sent to the error class, MessageNotUnderstood. So the frame immediately
below this is where the error happens. A bit further down we see that
D3DLOCKED_RECT is being sent #defineField:type:offset: with #Pitch,
SDWORDField and 0 as arguments.

(BTW, I'm not sure what the *** Bad Array means". Blair did tell me but
I've forgotten).

The next step would be to check the parameters. If we go and look at
the definition of ExternalStructure>>defineField:type:offset: we see
that is is defined as:

defineField: fieldName type: anExternalField offset: offset

Here we are passing an ExternalField subclass (SDWORDField) rather than
a subinstance (an instance of SDWORDField).

This is where I might start working from the other end of the stack to
see what the system was doing to cause this message and parameters to
be sent. Note that the bottom of the stack is not the bottom of the
file. The lower part of the file has the parameter stack  (rather than
the call stack) and we can leave that for now. Starting at the bottom
of the call stack where it says "<Bottom of stack>", we see:

---
{0AE6006C: cf 0AE60049, sp 0AE60080, bp 0AE60064, ip 7,
BlockClosure>>on:do:}
        receiver: [] @ 10 in InputState>>forkMain
        arg[0]: ProcessTermination
        arg[1]: [] @ 13 in BlockClosure>>newProcess

{0AE60048: cf 00000001, sp 0AE6005C, bp 0AE60048, ip 17, [] in
BlockClosure>>newProcess}
        receiver: [] @ 10 in InputState>>forkMain
---

Ok, so some time, months ago the main process in your image was started
by a call to #forkMain. Most probably this call was done back here at
Object Arts Central just before we released the image and it has been
lurking on the call stack ever since!

Looking *up* the stackfrom here we eventually get to the call to the
Lagoon Deployment Wizard that you made to deploy your application:

--
{0AE601D8: cf 0AE601B9, sp 0AE601EC, bp 0AE601D4, ip 275,
ImageStripper>>stripAndSaveNotifying:}
        receiver: a ImageStripper
        arg[0]: a Array
        env temp[0]: 'D:\My Documents\Dolphin Smalltalk
X6\SpriteDraw\test_dx9.exe'

{0AE601B8: cf 0AE6019D, sp 0AE601CC, bp 0AE601B8, ip 9,
ImageStripper>>stripAndSaveWithProgress}
        receiver: a ImageStripper
--

Keep going up until we join up with the place we found before where the
error was generated and we can see:

--
{0AE603CC: cf 0AE603AD, sp 0AE603E4, bp 0AE603CC, ip 8, D3DLOCKED_RECT
class>>defineFields}
        receiver: D3DLOCKED_RECT

{0AE603AC: cf 0AE60389, sp 0AE603C4, bp 0AE603A4, ip 35, D3DLOCKED_RECT
class(ExternalStructure class)>>defineTemplate}
        receiver: D3DLOCKED_RECT
        stack temp[0]: 0
        stack temp[1]: nil
--

So what do we know.

1) The error occurs inside a call to
ImageStripper>>stripAndSaveWithProgess.

2) The error is "SDWORDField class does not understand #alignment".

3) Eventually #stripAndSaveWithProgress calls D3DLOCKED_RECT
class>>defineTemplate.

4) The defineTemplate calls ExternalStructure
class>>defineField:type:offset: with an inappropriate type parameter.

I might then decide to trace through the #defineTemplate call in the
debugger to see where things go wrong. You could do this just in a
workspace by:

D3DLOCKED_RECT defineTemplate "Debug it"

Eventually, you should get to find that your template definition
contained an error (as you say it contained a "SDWORDField" rather than
"SDWORDField new").

I'm sorry about the length of this. As with all debugging, I think it
is harder to explain how it's done rather than to actually do it.
Anyway, I hope this helps a bit.

--
Best regards,

Andy Bower
Dolphin Support
www.object-arts.com

Andy,

Thank you for taking the time to post this. Honestly, the first time I
opened the .ERRORS file my eyes crossed. I just needed a quick cliff
notes or rosseta stone. :-)

Jeff M.

Hi Andy,

> I'm sorry about the length of this. As with all debugging, I think it
> is harder to explain how it's done rather than to actually do it.
> Anyway, I hope this helps a bit.

Nice response, and great way of helping us help ourselves. Probably would
have made a great blog entry on your site too ;-)

Tim