[VW7.4][Bug] Runtime image refers to change.log when loading parcels

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

[VW7.4][Bug] Runtime image refers to change.log when loading parcels

Andre Schnoor
Loading a parcel into a runtime image triggers
Parcel>>triggerParcelLoaded: aParcel, which in turn accesses the
change.log.

A really *strange* thing is that it happened on certain PCs only. Maybe
this is because the original change log was on a network path (e.g.
'\\host\dir\...') and OS installations behave differently here.

Anyway, there should be a safer means for intercepting source access in
runtime images. The #removeAllSources method doesn't seem to be water proof.

Andre


Reply | Threaded
Open this post in threaded view
|

Re: [VW7.4][Bug] Runtime image refers to change.log when loading parcels

Alan Knight-2
I'm not sure what you mean by accesses the change log. And I don't seem to see anything like this happening.

If I create a runtime image whose startup action is SimpleWorkspace open, copy the SUnitPreload parcel to my current directory (since the runtime has an empty parcel path) and then in the workspace that opens evaluate
   Parcel ensureLoaded: 'SUnitPreload' version: nil.

I don't see either an error message, or a change log created.

At 01:40 PM 30/05/2006, Andre Schnoor wrote:
>Loading a parcel into a runtime image triggers Parcel>>triggerParcelLoaded: aParcel, which in turn accesses the change.log.
>
>A really *strange* thing is that it happened on certain PCs only. Maybe this is because the original change log was on a network path (e.g. '\\host\dir\...') and OS installations behave differently here.
>
>Anyway, there should be a safer means for intercepting source access in runtime images. The #removeAllSources method doesn't seem to be water proof.
>
>Andre
>

--
Alan Knight [|], Cincom Smalltalk Development
[hidden email]
[hidden email]
http://www.cincom.com/smalltalk

"The Static Typing Philosophy: Make it fast. Make it right. Make it run." - Niall Ross

Reply | Threaded
Open this post in threaded view
|

Re: [VW7.4][Bug] Runtime image refers to change.log when loading parcels

Andre Schnoor

Unfortunately, debugging a runtime image is rather difficult. Maybe the
stack trace below can help.

BTW: The customized subclass of Parcel, RuntimeUpdateParcel, doesn't do
anything special in this regard, it just reimplements #binaryActions,
#propertiesForSave, #fileOutProperties:on: etc. I already fixed the
problem (for me) by reimplementing #triggerParcelLoaded: for this class,
i.e. this action is now completely ignored.

The runtime image was originally stripped and saved to
"t:\CS\deploy\export\nav-1.0.2\win\build\temp.im".
The network drive "T:" doesn't exist on a target system. I suspect
#noTargetForWrites doesn't respond correctly in all cases. It should
respond with false in a runtime image.

Regards,
Andre

--
ERROR_PATH_NOT_FOUND ("t:\CS\deploy\export\nav-1.0.2\win\build\temp.cha")

Stack Summary
[1] HandleRegistry>>evaluateWithFullProtection:
[2] HandleRegistry>>registerValueOf:
[3] PCDiskFileAccessor class(OSHandle class)>>handleValue:
[4] IOAccessor class>>openFileNamed:direction:creation:
[5] FileConnection>>open
[6] FileConnection>>revive
[7] ExternalWriteStream>>reopen
[8] ExternalWriteStream(BufferedExternalStream)>>openIfClosed
[9] ExternalWriteStream>>nextPut:
[10] ExternalReadAppendStream>>nextPut:
[11] UTF8StreamEncoder>>nextPut:on:
[12] EncodedStream>>nextPut:
[13] EncodedStream(Stream)>>next:putAll:startingAt:
[14] EncodedStream(Stream)>>nextPutAll:
[15] XMLSourceFileFormat>>checkForWrite:
[16] XMLSourceFileFormat>>loadParcel:filename:on:

.. should stop here in a runtime image ...

[17] SourceFileManager>>loadParcelNamed:filename:
[18] SourceFileManager>>loadParcel:
[19] RuntimeUpdateParcel class(Parcel class)>>triggerParcelLoaded:
[20] RuntimeUpdateParcel(Parcel)>>doComponentLoadedActions
[21] RuntimeUpdateParcel(CodeComponent)>>loadFrom:using:
[22] RuntimeUpdateParcel(CodeComponent)>>loadFrom:
[23] optimized [] in [] in [] in Parcel class>>
[24] BlockClosure>>on:do:
[25] optimized [] in [] in Parcel class>>
[26] BlockClosure>>on:do:
[27] [] in RuntimeUpdateParcel class(Parcel class)>>loadParcelCachedFrom:
[28] BlockClosure>>ensure:
[29] RuntimeUpdateParcel class(Parcel class)>>loadParcelCachedFrom:
[30] optimized [] in [] in Parcel class>>
[31] BlockClosure>>ensure:
[32] RuntimeUpdateParcel class(Parcel class)>>withFileCachesDo:
[33] optimized [] in Parcel class>>
[34] BlockClosure>>ensure:
[35] Cursor>>showWhile:
[36] RuntimeUpdateParcel class(Parcel class)>>loadParcelFrom:
...

Reply | Threaded
Open this post in threaded view
|

Re: [VW7.4][Bug] Runtime image refers to change.log when loading parcels

Alan Knight-2
Well, from the walkback, clearly the image has a change log and thinks it knows where it is. This is likely because of a known problem with three-step save, where the image isn't properly aware of its odd intermediate state between development and runtime, and attempts to put back the change log. This is fixed in 7.4.1. The simplest workaround is not to do a three-step save. Second simplest would I think be to force DevelopmentSystem and its methods to be deleted.

At 03:56 PM 30/05/2006, Andre Schnoor wrote:

>Unfortunately, debugging a runtime image is rather difficult. Maybe the stack trace below can help.
>
>BTW: The customized subclass of Parcel, RuntimeUpdateParcel, doesn't do anything special in this regard, it just reimplements #binaryActions, #propertiesForSave, #fileOutProperties:on: etc. I already fixed the problem (for me) by reimplementing #triggerParcelLoaded: for this class, i.e. this action is now completely ignored.
>
>The runtime image was originally stripped and saved to "t:\CS\deploy\export\nav-1.0.2\win\build\temp.im".
>The network drive "T:" doesn't exist on a target system. I suspect #noTargetForWrites doesn't respond correctly in all cases. It should respond with false in a runtime image.
>
>Regards,
>Andre
>
>--
>ERROR_PATH_NOT_FOUND ("t:\CS\deploy\export\nav-1.0.2\win\build\temp.cha")
>
>Stack Summary
>[1] HandleRegistry>>evaluateWithFullProtection:
>[2] HandleRegistry>>registerValueOf:
>[3] PCDiskFileAccessor class(OSHandle class)>>handleValue:
>[4] IOAccessor class>>openFileNamed:direction:creation:
>[5] FileConnection>>open
>[6] FileConnection>>revive
>[7] ExternalWriteStream>>reopen
>[8] ExternalWriteStream(BufferedExternalStream)>>openIfClosed
>[9] ExternalWriteStream>>nextPut:
>[10] ExternalReadAppendStream>>nextPut:
>[11] UTF8StreamEncoder>>nextPut:on:
>[12] EncodedStream>>nextPut:
>[13] EncodedStream(Stream)>>next:putAll:startingAt:
>[14] EncodedStream(Stream)>>nextPutAll:
>[15] XMLSourceFileFormat>>checkForWrite:
>[16] XMLSourceFileFormat>>loadParcel:filename:on:
>
>.. should stop here in a runtime image ...
>
>[17] SourceFileManager>>loadParcelNamed:filename:
>[18] SourceFileManager>>loadParcel:
>[19] RuntimeUpdateParcel class(Parcel class)>>triggerParcelLoaded:
>[20] RuntimeUpdateParcel(Parcel)>>doComponentLoadedActions
>[21] RuntimeUpdateParcel(CodeComponent)>>loadFrom:using:
>[22] RuntimeUpdateParcel(CodeComponent)>>loadFrom:
>[23] optimized [] in [] in [] in Parcel class>>
>[24] BlockClosure>>on:do:
>[25] optimized [] in [] in Parcel class>>
>[26] BlockClosure>>on:do:
>[27] [] in RuntimeUpdateParcel class(Parcel class)>>loadParcelCachedFrom:
>[28] BlockClosure>>ensure:
>[29] RuntimeUpdateParcel class(Parcel class)>>loadParcelCachedFrom:
>[30] optimized [] in [] in Parcel class>>
>[31] BlockClosure>>ensure:
>[32] RuntimeUpdateParcel class(Parcel class)>>withFileCachesDo:
>[33] optimized [] in Parcel class>>
>[34] BlockClosure>>ensure:
>[35] Cursor>>showWhile:
>[36] RuntimeUpdateParcel class(Parcel class)>>loadParcelFrom:
>...

--
Alan Knight [|], Cincom Smalltalk Development
[hidden email]
[hidden email]
http://www.cincom.com/smalltalk

"The Static Typing Philosophy: Make it fast. Make it right. Make it run." - Niall Ross