ODBReference does not understand #isImme

So I've not got my app all working nicely under D6 and getting to the
"lets build a deployable exe" stage again, before reworking my
automated build process.  When I deploy the exe, I see Dolphin go
through the the stripping process and just before it quits it crashes
and gives me the following in my .ERRORS file:

Anyone know what this is or what might be causing it?  I see
ODBReference descends from something called a ProtoObject???


(C:\WINDOWS\system32\kernel32.dll)

*----> Exception Parameters <----*
0A3A8780 ODBReference does not understand #isImmediate

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

*----> VM Context <----*
Process: {0BC90004:size 299 words, suspended frame 0BC90431, priority
5, callbacks 0
last failure 0:nil, FPE mask 3, thread 1157492}
Active Method: VMLibrary>>crashDump:
IP: 0A084D92 (18)
SP: 0BC90628
BP: 0BC905F8 (366)
ActiveFrame: {0BC90600: cf 0BC905DD, sp 00000000, bp 0BC905F8, ip 0,
VMLibrary>>crashDump:}
        receiver: a VMLibrary
        arg[0]: 'ODBReference does not understand #isImmediate'
        stack temp[0]: a ByteArray

Hmm - a quick forum search shows this is from STS, thou I coudn't see
anything that offered a solution :(

[hidden email] wrote:

> Anyone know what this is or what might be causing it?  I see
> ODBReference descends from something called a ProtoObject???

"Always deploy from a clean image", in this case that means one in which STS
has never run...

    -- chris

Hm, I dont agree with that since I always use STS for loading code and
deploy after I have loaded packages from the repository.

I think it will help if you just close all STS windows before deploying
(project editions browser, package editions browser, changes browser, etc.).

Anyway, this is probably something that I have to take care of.

Best regards,

David Gorisek



Chris Uppal wrote:

Can you write which STS windows were open at the time when you were
doing deployment?

I can not reproduce your problem.

Best regards,

David Gorisek



[hidden email] wrote:

David,

[me:]
> > "Always deploy from a clean image", in this case that means one in
> > which STS has never run...

> Hm, I dont agree with that [...]

I thought that might get a rise out of you ;-)

I agree that it would be better if "clean image" could include STS.

    -- chris

Just got back to the office after the weekend - I don't have ANY STS
windows open.  The only thing I have open is a workspace where I ran:

SessionManager inputState queueDeferredAction: (
  MessageSend receiver: (
    Package manager packageNamed: 'SMSComposer') imageStripper
      selector: #stripAndSaveWithProgress)

which I snipped from my old auto-build script.

Ok, but have you used STS before evaluating this script?

During normal deployment using Dolphin Lagoon, STS will close repository
database before doing stripping. In your case it looks like appropriate
events are not being sent, so the STS repository remains open and then
you get the errors. I would suggest doing " StsManager shutdown " before
running your build script.

Best regards,

David Gorisek



[hidden email] wrote:

Havn't used STS in the session no, but in the image certainly....

Running StsManager shutdown before stripping seemed to give me the same
problem as well :(

Any other suggestions at all? "StsManager shutdown" gave no love...

You will have to find out who is referencing the remaining proxy
objects. It looks like the OmniBase package is uninstalled, but there
are still proxies left in the image. Because the package is uninstalled,
the method #isImmediate is not present anymore, so you get an error.

I would do the following:

1. StsManager shutdown.
2. then check if there are any other OmniBase sessions open by doing
OmniBase allSessions
3. check for all instances of ODBReference
4. if there are any, check who is referencing them

Also, are you building from a fresh image or could there by some
left-overs from previous development sessions where you've been using
OmniBase (or STS).

Best regards,

David Gorisek



[hidden email] wrote:
> Any other suggestions at all? "StsManager shutdown" gave no love...
>

'OmniBase allSessions' returns an empty collection.

'ODBReference instanceCount' returns 6.

Inspecting 'ODBReference allInstances' opens an array inspector but
throws the following exception:

9:49:24 a.m., Wednesday, 12 April 2006: 'UndefinedObject does not
understand #holderAt:'
Object>>doesNotUnderstand:
ODBLocalTransaction(ODBTransaction)>>transactionObjectAt:
ODBDemandLoader>>getObject
ODBDemandLoader>>perform:withArguments:
ODBReference>>doesNotUnderstand:
[] in KeyedAspectBatchAccessor>>getBatchAccessors
[] in SequenceableCollection>>from:to:do:
Interval>>uncheckedFrom:to:keysAndValuesDo:
Interval(SequenceableCollection)>>from:to:keysAndValuesDo:
Interval(SequenceableCollection)>>from:to:do:
KeyedAspectBatchAccessor>>getBatchAccessors
Array(SequenceableCollection)>>publishedKeyedAspects
Array(Collection)>>publishedAspects
PublishedAspectInspector>>modelAspect
PublishedAspectInspector>>refresh
PublishedAspectInspector>>onValueChanged
EventMessageSend>>forwardTo:withArguments:
EventMessageSend>>value
[] in MessageSequenceAbstract>>value
EventMessageSequence>>messagesDo:
EventMessageSequence(MessageSequenceAbstract)>>value
EventsCollection>>triggerEvent:
ValueHolder(Object)>>trigger:
ValueHolder(ValueModel)>>notifyChanged
ValueHolder(ValueModel)>>value:
FlipperInspector>>value:
FlipperInspector class>>shellOn:
RefactoringSmalltalkSystem(SmalltalkSystem)>>inspect:
Array(Object)>>inspect
SmalltalkWorkspace>>inspectIt
Symbol>>forwardTo:
CommandDescription>>performAgainst:
[] in Command>>value
BlockClosure>>ifCurtailed:
BlockClosure>>ensure:
Command>>value
ShellView>>performCommand:
SmalltalkWorkspaceDocument(Shell)>>performCommand:
CommandQuery>>perform
DelegatingCommandPolicy(CommandPolicy)>>route:
[] in ShellView(View)>>onCommand:
BlockClosure>>ifCurtailed:
BlockClosure>>ensure:
Cursor>>showWhile:
ShellView(View)>>onCommand:
ShellView(View)>>wmCommand:wParam:lParam:
ShellView(View)>>dispatchMessage:wParam:lParam:
[] in InputState>>wndProc:message:wParam:lParam:cookie:
BlockClosure>>ifCurtailed:
ProcessorScheduler>>callback:evaluate:

This was originally a fresh image but I'd done some STS commits.  I'll
try again from a fresh image.

Created a fresh image, loaded the packages, strip to exe seemed to work
fine now.

Now to work out why the app doesn't seem to run, I suspect I've lost a
reference to my custom session manager.

Getting closer to being back on track again...