Runtime Image Stripping Woes
Locked
12
12
 
|
Hi all,
the runtime image stripper (RuntimePackager of 7.5) currently drives me nuts, because it strips so many methods that it effectively strips itself to death (i.e. the build script doesn't complete anymore). This is new (worked fine the day before). It happened out of a sudden, literally overnight. After examining my recent changes to the application code, I found nothing suspicious that might cause methods to leak the tracer. The overall code didn't change much anyway. The most weird thing is it even strips ProcessScheduler>>systemRockBottomPriority (referenced in Process>>initialize, needed all the time), and UILookPolicy>>topCompositeClass (needed by UIBuilder all the time) and similar core stuff. This never happened before. How could something basic like that, which is definitely referenced by reachable code, be stripped in the first place? What the heck? To narrow down the problem, I printed a report showing which globals, classes and methods the tracer found to be "unreferenced" -- some of them are definitely NOT unreferenced. They are in the middle of the Smalltalk universe. As the tracer and packager rely on huge sets, I checked whether something went wrong with IdentitySet, with hashes, SmallInteger overflows or the like, but to no avail. I'm using the original 7.5 VM and RuntimePackager on Windows. The same problems arise on MacOS X. Does anyone have any idea how to narrow down this issue? Similar experiences to share? Any pointer is highly appreciated. Andre |
Re: Runtime Image Stripping Woes
|
|
I just bailed on the idea of having RTP strip <anything>. I tell it
to keep every package, and just have it prepare the image. I then use the Image Compressor to make the shipping image smaller, and the VM handles decompressing it at startup. Not ideal, but it works On Feb 14, 2008, at 8:40 AM, Andre Schnoor wrote: > Hi all, > > the runtime image stripper (RuntimePackager of 7.5) currently drives > me nuts, because it strips so many methods that it effectively > strips itself to death (i.e. the build script doesn't complete > anymore). > > This is new (worked fine the day before). It happened out of a > sudden, literally overnight. After examining my recent changes to > the application code, I found nothing suspicious that might cause > methods to leak the tracer. The overall code didn't change much > anyway. > > The most weird thing is it even strips > ProcessScheduler>>systemRockBottomPriority (referenced in > Process>>initialize, needed all the time), and > UILookPolicy>>topCompositeClass (needed by UIBuilder all the time) > and similar core stuff. This never happened before. How could > something basic like that, which is definitely referenced by > reachable code, be stripped in the first place? What the heck? > > To narrow down the problem, I printed a report showing which > globals, classes and methods the tracer found to be "unreferenced" > -- some of them are definitely NOT unreferenced. They are in the > middle of the Smalltalk universe. > > As the tracer and packager rely on huge sets, I checked whether > something went wrong with IdentitySet, with hashes, SmallInteger > overflows or the like, but to no avail. I'm using the original 7.5 > VM and RuntimePackager on Windows. The same problems arise on MacOS X. > > Does anyone have any idea how to narrow down this issue? Similar > experiences to share? Any pointer is highly appreciated. > > Andre > > |
RE: Runtime Image Stripping Woes
|
|
In reply to this post by Andre Schnoor
IMHO, this no longer needs to be a problem. Back in the days of 64MB
memory and 2GB hard drives, you had to strip as much as possible out of your image. Today, though, "strip nothing" is a perfectly valid strategy. Thomas Sattler Morgan Stanley | Technology 750 Seventh Avenue, 14th Floor | New York, NY 10019 Phone: +1 212 762-1212 [hidden email] > -----Original Message----- > From: [hidden email] [mailto:[hidden email]] > Sent: Thursday, February 14, 2008 8:40 AM > To: vwnc-list > Subject: Runtime Image Stripping Woes > > Hi all, > > the runtime image stripper (RuntimePackager of 7.5) currently > drives me nuts, because it strips so many methods that it > effectively strips itself to death (i.e. the build script > doesn't complete anymore). > > This is new (worked fine the day before). It happened out of > a sudden, literally overnight. After examining my recent > changes to the application code, I found nothing suspicious > that might cause methods to leak the tracer. The overall code > didn't change much anyway. > > The most weird thing is it even strips > ProcessScheduler>>systemRockBottomPriority (referenced in > Process>>initialize, needed all the time), and > UILookPolicy>>topCompositeClass (needed by UIBuilder all the time) and > similar core stuff. This never happened before. How could > something basic like that, which is definitely referenced by > reachable code, be stripped in the first place? What the heck? > > To narrow down the problem, I printed a report showing which > globals, classes and methods the tracer found to be > "unreferenced" -- some of them are definitely NOT > unreferenced. They are in the middle of the Smalltalk universe. > > As the tracer and packager rely on huge sets, I checked > whether something went wrong with IdentitySet, with hashes, > SmallInteger overflows or the like, but to no avail. I'm > using the original 7.5 VM and RuntimePackager on Windows. The > same problems arise on MacOS X. > > Does anyone have any idea how to narrow down this issue? > Similar experiences to share? Any pointer is highly appreciated. > > Andre > > NOTICE: If received in error, please destroy and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error. |
FW: Runtime Image Stripping Woes
|
|
In reply to this post by Andre Schnoor
Cool .... I thought it was me....I was having the same issue. We converted from 3.x to 7.x and the RTP in 7.x strips out everything to the point where it is useless!!!
-----Original Message----- From: James Robertson [mailto:[hidden email]] Sent: Thursday, February 14, 2008 8:56 AM To: [hidden email] Subject: Re: Runtime Image Stripping Woes I just bailed on the idea of having RTP strip <anything>. I tell it to keep every package, and just have it prepare the image. I then use the Image Compressor to make the shipping image smaller, and the VM handles decompressing it at startup. Not ideal, but it works On Feb 14, 2008, at 8:40 AM, Andre Schnoor wrote: > Hi all, > > the runtime image stripper (RuntimePackager of 7.5) currently drives > me nuts, because it strips so many methods that it effectively > strips itself to death (i.e. the build script doesn't complete > anymore). > > This is new (worked fine the day before). It happened out of a > sudden, literally overnight. After examining my recent changes to > the application code, I found nothing suspicious that might cause > methods to leak the tracer. The overall code didn't change much > anyway. > > The most weird thing is it even strips > ProcessScheduler>>systemRockBottomPriority (referenced in > Process>>initialize, needed all the time), and > UILookPolicy>>topCompositeClass (needed by UIBuilder all the time) > and similar core stuff. This never happened before. How could > something basic like that, which is definitely referenced by > reachable code, be stripped in the first place? What the heck? > > To narrow down the problem, I printed a report showing which > globals, classes and methods the tracer found to be "unreferenced" > -- some of them are definitely NOT unreferenced. They are in the > middle of the Smalltalk universe. > > As the tracer and packager rely on huge sets, I checked whether > something went wrong with IdentitySet, with hashes, SmallInteger > overflows or the like, but to no avail. I'm using the original 7.5 > VM and RuntimePackager on Windows. The same problems arise on MacOS X. > > Does anyone have any idea how to narrow down this issue? Similar > experiences to share? Any pointer is highly appreciated. > > Andre > > |
Re: Runtime Image Stripping Woes
|
|
In reply to this post by Sattler, Thomas (IT)
We do our own preparation for deployment, and we strip our only
our own classes which we know a particular client does not need. Sure makes life a lot simpler -- and yes our images tend to be about 90Mb, but we don't really care all that much. Sattler, Thomas (IT) wrote: IMHO, this no longer needs to be a problem. Back in the days of 64MB memory and 2GB hard drives, you had to strip as much as possible out of your image. Today, though, "strip nothing" is a perfectly valid strategy. Thomas Sattler Morgan Stanley | Technology 750 Seventh Avenue, 14th Floor | New York, NY 10019 Phone: +1 212 762-1212 [hidden email]-----Original Message----- From: [hidden email] [[hidden email]] Sent: Thursday, February 14, 2008 8:40 AM To: vwnc-list Subject: Runtime Image Stripping Woes Hi all, the runtime image stripper (RuntimePackager of 7.5) currently drives me nuts, because it strips so many methods that it effectively strips itself to death (i.e. the build script doesn't complete anymore). This is new (worked fine the day before). It happened out of a sudden, literally overnight. After examining my recent changes to the application code, I found nothing suspicious that might cause methods to leak the tracer. The overall code didn't change much anyway. The most weird thing is it even strips ProcessScheduler>>systemRockBottomPriority (referenced in Process>>initialize, needed all the time), and UILookPolicy>>topCompositeClass (needed by UIBuilder all the time) and similar core stuff. This never happened before. How could something basic like that, which is definitely referenced by reachable code, be stripped in the first place? What the heck? To narrow down the problem, I printed a report showing which globals, classes and methods the tracer found to be "unreferenced" -- some of them are definitely NOT unreferenced. They are in the middle of the Smalltalk universe. As the tracer and packager rely on huge sets, I checked whether something went wrong with IdentitySet, with hashes, SmallInteger overflows or the like, but to no avail. I'm using the original 7.5 VM and RuntimePackager on Windows. The same problems arise on MacOS X. Does anyone have any idea how to narrow down this issue? Similar experiences to share? Any pointer is highly appreciated. Andre-------------------------------------------------------- NOTICE: If received in error, please destroy and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error. -- Dennis Smith +1 416.798.7948 Cherniak Software Development Corporation Fax: +1 416.798.0948 509-2001 Sheppard Avenue East [hidden email] Toronto, ON M2J 4Z8 [hidden email] Canada http://www.CherniakSoftware.com Entrance off Yorkland Blvd south of Sheppard Ave east of the DVP |
|
|
In reply to this post by Sattler, Thomas (IT)
>IMHO, this no longer needs to be a problem. Back in the days of 64MB
>memory and 2GB hard drives, you had to strip as much as possible out of >your image. Today, though, "strip nothing" is a perfectly valid >strategy. Depends on your application. For our work, we need things to be as small as possible. The Runtime Packager should work, or else there should be a build up from a minimal (really small) image model. -Carl Gundel http://www.libertybasic.com |
RE: Runtime Image Stripping Woes
|
|
James
A couple of versions ago there was some direction to partition the image so a build up strategy would be feasible. Now, in your roadmap there seems to be no mention of it, what happened?? Terry =========================================================== Terry Raymond Crafted Smalltalk 80 Lazywood Ln. Tiverton, RI 02878 (401) 624-4517 [hidden email] <http://www.craftedsmalltalk.com> =========================================================== > -----Original Message----- > From: Carl Gundel [mailto:[hidden email]] > Sent: Thursday, February 14, 2008 9:15 AM > To: vwnc-list > Subject: Re: Runtime Image Stripping Woes > > >IMHO, this no longer needs to be a problem. Back in the days of 64MB > >memory and 2GB hard drives, you had to strip as much as possible out of > >your image. Today, though, "strip nothing" is a perfectly valid > >strategy. > > Depends on your application. For our work, we need things to be as small > as > possible. The Runtime Packager should work, or else there should be a > build > up from a minimal (really small) image model. > > -Carl Gundel > http://www.libertybasic.com |
Re: Runtime Image Stripping Woes
|
|
In reply to this post by Sattler, Thomas (IT)
Sattler, Thomas (IT) wrote:
> IMHO, this no longer needs to be a problem. Back in the days of 64MB > memory and 2GB hard drives, you had to strip as much as possible out of > your image. Today, though, "strip nothing" is a perfectly valid > strategy. > Sure. I don't care about the typical snippets of "dead code" that occur in every application. What really concerns me are those loads of development, intermediate, UI and other redundant packages that have *nothing* to do with my application at all. I don't want to ship this bloated garbage to customers. Not only for reasons of footprint and bandwidth (download). I also consider this a security threat. My stripped images are about 6-7MB when compressed, which is ok. I want to keep it at that. I wish there was a tool for building runtime images from scratch, where the tools are separated from the product they are building. Every other IDE has it. The lack of subject-object separation causes a lot of problems. No wonder: Images are required to "build themselves". NO, this is not elegant or cool. It's a clear disadvantage causing a lot of extra cost and hassle. Andre |
RE: Runtime Image Stripping Woes
|
|
Andre,
Building runtime images is *one* way to distribute the app, but not the only way. At Morgan Stanley, we have a small base image which reads a configuration file passed to it on the unix command line. That config file has a number of "loadParcel" statements (which do exactly what you'd suspect they do), ending with a command to start and run the desired application. I create a base image whenever we upgrade (which isn't too often), and we just create new parcels when we want to add new features to the application. Thomas Sattler Morgan Stanley | Technology 750 Seventh Avenue, 14th Floor | New York, NY 10019 Phone: +1 212 762-1212 [hidden email] > -----Original Message----- > From: [hidden email] [mailto:[hidden email]] > Sent: Thursday, February 14, 2008 10:00 AM > To: Sattler, Thomas (IT) > Cc: vwnc-list > Subject: Re: Runtime Image Stripping Woes > > Sattler, Thomas (IT) wrote: > > IMHO, this no longer needs to be a problem. Back in the > days of 64MB > > memory and 2GB hard drives, you had to strip as much as > possible out > > of your image. Today, though, "strip nothing" is a perfectly valid > > strategy. > > > > Sure. I don't care about the typical snippets of "dead code" > that occur in every application. What really concerns me are > those loads of development, intermediate, UI and other > redundant packages that have > *nothing* to do with my application at all. I don't want to > ship this bloated garbage to customers. Not only for reasons > of footprint and bandwidth (download). I also consider this a > security threat. > > My stripped images are about 6-7MB when compressed, which is > ok. I want to keep it at that. > > I wish there was a tool for building runtime images from > scratch, where the tools are separated from the product they > are building. Every other IDE has it. The lack of > subject-object separation causes a lot of problems. No > wonder: Images are required to "build themselves". NO, this > is not elegant or cool. It's a clear disadvantage causing a > lot of extra cost and hassle. > > Andre > > NOTICE: If received in error, please destroy and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error. |
Re: Runtime Image Stripping Woes
|
|
In reply to this post by Andre Schnoor
I' have seen similar behavior in the past.
What was happening we had newer version of RTP and were using the config file generated by previous release. It did cause all sort of intractable problems. Could you try to build your Image from scratch manually, test your application in the RTP , etc... In general I do think that stripping is important - "we have plenty of disk and RAM" excuse does sound a bit lame. The major problem with the stripping as it stands now - the base image does not behave the same as the development in some key area. I had to deal with one - largely due to the PDP package process/exception handling (non)integration - that one I found and fixed but there might be others as well. Andre Schnoor wrote: > Hi all, > > the runtime image stripper (RuntimePackager of 7.5) currently drives me > nuts, because it strips so many methods that it effectively strips > itself to death (i.e. the build script doesn't complete anymore). > > This is new (worked fine the day before). It happened out of a sudden, > literally overnight. After examining my recent changes to the > application code, I found nothing suspicious that might cause methods to > leak the tracer. The overall code didn't change much anyway. > > The most weird thing is it even strips > ProcessScheduler>>systemRockBottomPriority (referenced in > Process>>initialize, needed all the time), and > UILookPolicy>>topCompositeClass (needed by UIBuilder all the time) and > similar core stuff. This never happened before. How could something > basic like that, which is definitely referenced by reachable code, be > stripped in the first place? What the heck? > > To narrow down the problem, I printed a report showing which globals, > classes and methods the tracer found to be "unreferenced" -- some of > them are definitely NOT unreferenced. They are in the middle of the > Smalltalk universe. > > As the tracer and packager rely on huge sets, I checked whether > something went wrong with IdentitySet, with hashes, SmallInteger > overflows or the like, but to no avail. I'm using the original 7.5 VM > and RuntimePackager on Windows. The same problems arise on MacOS X. > > Does anyone have any idea how to narrow down this issue? Similar > experiences to share? Any pointer is highly appreciated. > > Andre > > > |
RE: Runtime Image Stripping Woes
|
|
Mark,
Not sure if the "we have plenty of disk and RAM" excuse is lame or not, but even if it is, what we don't have (at least here at Morgan Stanley) is an unlimited amount of resources to get things done. My management will not be impressed if I can reduce the base image's size by another 20 percent, at the expense of getting work done for the business unit. --Tom Thomas Sattler Morgan Stanley | Technology 750 Seventh Avenue, 14th Floor | New York, NY 10019 Phone: +1 212 762-1212 [hidden email] > -----Original Message----- > From: Mark Pirogovsky [mailto:[hidden email]] > Sent: Thursday, February 14, 2008 10:08 AM > To: Andre Schnoor > Cc: vwnc-list > Subject: Re: Runtime Image Stripping Woes > > I' have seen similar behavior in the past. > What was happening we had newer version of RTP and were using > the config file generated by previous release. It did cause > all sort of intractable problems. > > Could you try to build your Image from scratch manually, test > your application in the RTP , etc... > > In general I do think that stripping is important - "we have > plenty of disk and RAM" excuse does sound a bit lame. > > The major problem with the stripping as it stands now - the > base image does not behave the same as the development in > some key area. I had to deal with one - largely due to the > PDP package process/exception handling (non)integration - > that one I found and fixed but there might be others as well. > > Andre Schnoor wrote: > > Hi all, > > > > the runtime image stripper (RuntimePackager of 7.5) > currently drives > > me nuts, because it strips so many methods that it > effectively strips > > itself to death (i.e. the build script doesn't complete anymore). > > > > This is new (worked fine the day before). It happened out > of a sudden, > > literally overnight. After examining my recent changes to the > > application code, I found nothing suspicious that might > cause methods > > to leak the tracer. The overall code didn't change much anyway. > > > > The most weird thing is it even strips > > ProcessScheduler>>systemRockBottomPriority (referenced in > > Process>>initialize, needed all the time), and > > UILookPolicy>>topCompositeClass (needed by UIBuilder all > the time) and > > similar core stuff. This never happened before. How could something > > basic like that, which is definitely referenced by > reachable code, be > > stripped in the first place? What the heck? > > > > To narrow down the problem, I printed a report showing > which globals, > > classes and methods the tracer found to be "unreferenced" > -- some of > > them are definitely NOT unreferenced. They are in the middle of the > > Smalltalk universe. > > > > As the tracer and packager rely on huge sets, I checked whether > > something went wrong with IdentitySet, with hashes, SmallInteger > > overflows or the like, but to no avail. I'm using the > original 7.5 VM > > and RuntimePackager on Windows. The same problems arise on MacOS X. > > > > Does anyone have any idea how to narrow down this issue? Similar > > experiences to share? Any pointer is highly appreciated. > > > > Andre > > > > > > > > NOTICE: If received in error, please destroy and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error. |
RE: Runtime Image Stripping Woes
|
|
In reply to this post by Sattler, Thomas (IT)
I know of other customers who use a similar strategy. They actually
built a nice tool set to release parcels and have a command file that runs the base image with a .cnf file to load the parcels and a doit command line that starts the application up. In this way they use common parcels and specific application parcels for each application the deploy and use. They then simply build a small runtime when the new release is out. I do believe though they leave in the base development tools in their case because of the need to turn on the debugger and debug an issues on a users box. The application is internal so they can have larger base runtimes images. However you could strip more out and have a base runtime that is smaller. Sean -----Original Message----- From: Sattler, Thomas (IT) [mailto:[hidden email]] Sent: Thursday, February 14, 2008 8:05 AM To: [hidden email] Cc: vwnc-list Subject: RE: Runtime Image Stripping Woes Andre, Building runtime images is *one* way to distribute the app, but not the only way. At Morgan Stanley, we have a small base image which reads a configuration file passed to it on the unix command line. That config file has a number of "loadParcel" statements (which do exactly what you'd suspect they do), ending with a command to start and run the desired application. I create a base image whenever we upgrade (which isn't too often), and we just create new parcels when we want to add new features to the application. Thomas Sattler Morgan Stanley | Technology 750 Seventh Avenue, 14th Floor | New York, NY 10019 Phone: +1 212 762-1212 [hidden email] > -----Original Message----- > From: [hidden email] [mailto:[hidden email]] > Sent: Thursday, February 14, 2008 10:00 AM > To: Sattler, Thomas (IT) > Cc: vwnc-list > Subject: Re: Runtime Image Stripping Woes > > Sattler, Thomas (IT) wrote: > > IMHO, this no longer needs to be a problem. Back in the > days of 64MB > > memory and 2GB hard drives, you had to strip as much as > possible out > > of your image. Today, though, "strip nothing" is a perfectly valid > > strategy. > > > > Sure. I don't care about the typical snippets of "dead code" > that occur in every application. What really concerns me are > those loads of development, intermediate, UI and other > redundant packages that have > *nothing* to do with my application at all. I don't want to > ship this bloated garbage to customers. Not only for reasons > of footprint and bandwidth (download). I also consider this a > security threat. > > My stripped images are about 6-7MB when compressed, which is > ok. I want to keep it at that. > > I wish there was a tool for building runtime images from > scratch, where the tools are separated from the product they > are building. Every other IDE has it. The lack of > subject-object separation causes a lot of problems. No > wonder: Images are required to "build themselves". NO, this > is not elegant or cool. It's a clear disadvantage causing a > lot of extra cost and hassle. > > Andre > > NOTICE: If received in error, please destroy and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error. |
Re: Runtime Image Stripping Woes
|
|
In reply to this post by Andre Schnoor
Isn't security greatly compromised with all these arbitrary doits and parcel loads happening at runtime? Say, key logger and whatnot? |
Re: Runtime Image Stripping Woes
|
|
In reply to this post by Sattler, Thomas (IT)
Sattler, Thomas (IT) wrote:
> Building runtime images is *one* way to distribute the app, but not the > only way. At Morgan Stanley, we have a small base image which reads a > configuration file passed to it on the unix command line. That config > file has a number of "loadParcel" statements (which do exactly what > you'd suspect they do), ending with a command to start and run the > desired application. I create a base image whenever we upgrade (which > isn't too often), and we just create new parcels when we want to add new > features to the application. > I agree this is a viable way to go for certain types of applications. If I ever move Cognitone's ERP to VW, I'll probably do it this way. However, it doesn't work for shrink-wrapped products sold to the public (or other hostile environments). Apart from the security problem, the requirements for desktop apps are different: Launch time, for instance, is of the essence as documents are double-clicked on the user's desktop and programs tend to be opened/closed rather frequently. Andre |
RE: Runtime Image Stripping Woes
|
|
In reply to this post by Boris Popov, DeepCove Labs (SNN)
I agree and you could double click on the cmd file or shell script
to launch the app. But most shrink wrapped apps that would not be an option. I
do believe it is part of our strategy moving forward to make deployment and
easier and more sane process. Sean From: Boris Popov
[mailto:[hidden email]] Isn't security
greatly compromised with all these arbitrary doits and parcel loads happening at
runtime? Say, key logger and whatnot? |
Re: Runtime Image Stripping Woes
|
|
In reply to this post by Mark Pirogovsky-3
Hi Mark,
thanks for your suggestion. > Could you try to build your Image from scratch manually, test your > application in the RTP , etc... I'm not using configuration settings, but run RTP programmatically from my own build environment instead. This worked fine until Monday. I isolated the bug (or whatever it is) to be related to the message tracer. It's clear that some methods are found to be unreferenced that are clearly referenced inside the base image. They are actually required for any Process that is forked (Process>>initialize bombs) or arbitrary Window that is opened. Hence the issue is not related to my applications specifically. From what I can see at the moment, it seems the accidentally stripped methods are referenced only /once/. I'll have to check whether this observation leads to something. Another weird thing is: How come that Kernel.Undeclared.Error, Kernel.Undeclared.Object etc. happen to occur in the unreferenced globals reported by the tracer? There are more of them (Array, Delay, ...). How could these core things ever have been (temporarily) undeclared? Does this happen when reading from Store? > In general I do think that stripping is important - "we have plenty of > disk and RAM" excuse does sound a bit lame. Whether it's stripping or some tool for building-up. There should be a way to create robust products with a reasonable footprint. Andre |
Re: Runtime Image Stripping Woes
|
|
In reply to this post by Andre Schnoor
The most obvious technique to diagnose this if it worked the
day before is to run it on the version from the day before, dump out the
list of stuff it things it's saving/deleting, do it with today's version,
and then diff them.
Another technique is to run the "Test Application" in the runtime packager and see which dynamically added references it comes up with. As far as other comments in the thread. If you want to create an image from a small base without stripping, you can use base.im and load parcels into it from the command line. At that point you can either run runtime packager on it without stripping to have it do things like install runtime exception handling and turn off the ability to command-line load parcels and run doits. Or you could just do those things yourself. In 7.6, some of that functionality, notably the exception handling and logging, has been removed from runtime packager and put into the base image. This also allows us to unload the old (non-PDP debugger) from base.im, because now an unhandled exception can produce a stack dump rather than a debugger. So work on getting the image partitioned better to allow starting from smaller bases continues incrementally. Also note things like the -runtime flag for testing behaviour, and the ability to save an image as runtime by doing something like "DeploymentOptionsSystem current startInRuntime: true. ObjectMemory snapshotAs: ImagePath thenQuit: false". 7.X is not a very descriptive version number, and the behaviour of runtime packager is likely to be different in different 7.X versions. There is a known issue with using old config files, as they weren't being updated to the default set of kept items, and in some versions the default set of kept items wasn't as large as it ought to be. Most notably, in some older versions parts of the Subsystem hierarchy could be stripped, with bad results. That's not the same as the problem Andre was having, though. At 08:40 AM 2/14/2008, Andre Schnoor wrote: Hi all, --
Alan Knight [|], Cincom Smalltalk Development
|
Undeclareds (Re: Runtime Image Stripping Woes)
|
|
In reply to this post by Andre Schnoor
On Feb 14, 2008, at 5:09 PM, Andre Schnoor wrote: > > Another weird thing is: How come that Kernel.Undeclared.Error, > Kernel.Undeclared.Object etc. happen to occur in the unreferenced > globals reported by the tracer? There are more of them (Array, > Delay, ...). How could these core things ever have been > (temporarily) undeclared? Does this happen when reading from Store? Note that it is not 'these things' getting undeclared but that it works the other way around: only /some/ code could not resolve those names so they end up in Undeclared. I'd guess that could happen if a class definition is overridden with code that belongs to an older version of VW or your app (the imports are not compatible). R - |
Re: Undeclareds (Re: Runtime Image Stripping Woes)
|
|
Reinout Heeck wrote:
> On Feb 14, 2008, at 5:09 PM, Andre Schnoor wrote: >> Another weird thing is: How come that Kernel.Undeclared.Error, >> Kernel.Undeclared.Object etc. happen to occur in the unreferenced >> globals reported by the tracer? There are more of them (Array, Delay, >> ...). How could these core things ever have been (temporarily) >> undeclared? Does this happen when reading from Store? > > Note that it is not 'these things' getting undeclared but that it > works the other way around: only /some/ code could not resolve those > names so they end up in Undeclared. I'd guess that could happen if a > class definition is overridden with code that belongs to an older > version of VW or your app (the imports are not compatible). > Hm, that's interesting. Thanks for pointing me to it. Although I still wonder how it could happen that "Object" could not be resolved. Andre |
Re: Runtime Image Stripping Woes
|
|
In reply to this post by Andre Schnoor
Alan Knight wrote:
The most obvious technique to diagnose this if it worked the day before is to run it on the version from the day before, dump out the list of stuff it things it's saving/deleting, do it with today's version, and then diff them. This is what I wanted to do, but Store doesn't support product configurations (with versioned prerequisites) beyond the bundle scope. I will need to load all the bundles and packages manually, picking the right version for each and see. Whether this will lead to the same results as running the automated script, dunno. It's worth a try. Good idea. I doubt it would strip the methods required to fork a block or to open a window. There must be something else gone wrong here. As far as other comments in the thread. If you want to create an image from a small base without stripping, you can use base.im and load parcels into it from the command line. At that point you can either run runtime packager on it without stripping to have it do things like install runtime exception handling and turn off the ability to command-line load parcels and run doits. Yep. My plan is to move away from using Store in the build script. Step 1 would be to load from Store and create and save the parcel files. I've got a ParcelBuilder that can save the whole product as a single parcel. Step 2 would load this parcel in the way you describe. Step 3 would then seal the image and strip a few critical things (command line, compiler, etc). In 7.6, some of that functionality, notably the exception handling and logging, has been removed from runtime packager and put into the base image.That's a very good move. Andre |
«
Return to VisualWorks
|
1 view|%1 views
| Free forum by Nabble | Edit this page |