Primitive Process>>primTerminate failed (0)

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

Re: Primitive Process>>primTerminate failed (0)

Schwab,Wilhelm K
Joseph,

> The application runs perfectly in the development image.  And I was even
> able to generate one working executable (only one).

The things that come to mind are a "memory effect" due to something
(background process, zombie view, etc.) saved in the image, or (almost
the same thing) that you made a code change that broke it.

Remember that you are working on a running system, and there are a few
potential snags that come along with all of the benefits.  Some people
do not generally save images, building a fresh one from packages at
every opportunity.  I save images over long periods of time, but am
_very_ careful about when I allow myself to save it; it might be more
accurate to say that I have a list of conditions under which I refuse to
save it.

Keywords such as image, save, dangerous, backup, and the infamous
bonkers (sorry Andy...<g>) will take you to lots of discussion on the
pros and cons of both approaches.

Have a good one,

Bill

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


Reply | Threaded
Open this post in threaded view
|

Re: Primitive Process>>primTerminate failed (0)

Ian Bartholomew-21
In reply to this post by Joseph Frippiat
Joseph,

I saw the same errors when deploying my SerialChat package.

The problem is that it was not designed to be deployed as such - it was
just a demo for the Serial package and I only envisioned it being used
from within the image.  To make it deployable you need to do the
following - nb. step 5 is important

1) Load the package into a clean image
2) Delete the SerialChat class methods #initialize and #uninitialize
3) Move the SerialChat class to become a subclass of Shell
4) Save the package
5) Exit the image without saving
6) Restart the image and reload the package

You should now be able to deploy your application - SerialChat works
anyway :-)

Let us know how you get on.

--
Ian

Use the Reply-To address to contact me (limited validity).
Mail sent to the From address is ignored.


Reply | Threaded
Open this post in threaded view
|

Re: Primitive Process>>primTerminate failed (0)

Andy Bower-3
In reply to this post by Chris Uppal-3
Chris,

> Lastly (for now).  You are deploying from a clean image aren't you ?
> I can't think why I didn't ask before.  I know that it annoys Andy
> when I say this, but I still think it's good advice: NEVER deploy
> from anything except a clean image.

Actually, it doesn't annoy me at all since I would certainly recommend
this for final deployments or ones (like this) where something is going
wrong. After all we've just deployed DCE from a fresh booted image too.

Best regards

--
Andy Bower
Dolphin Support
www.object-arts.com


Reply | Threaded
Open this post in threaded view
|

Re: Primitive Process>>primTerminate failed (0)

Ian Bartholomew-21
In reply to this post by Chris Uppal-3
Chris et al,

Just FYI.

I'm not sure why the walkbacks were occurring, I didn't track it all the
way, but the problems were

1) When the package was loaded the class initialized itself as a Dolphin
"Sample Application"
2) Because of the position in the class hierarchy it used the
#defaultModel class method in SmalltalkToolShell - which answered an
instance of SmalltalkSystem

Neither of these appear to work very well after a strip so it's not
surprising it didn't get very far.

Unfortunately, in this case, the methods that we all suggested to Joseph
for tracking down the problem wouldn't have helped much. ;-(

--
Ian

Use the Reply-To address to contact me (limited validity).
Mail sent to the From address is ignored.


Reply | Threaded
Open this post in threaded view
|

Re: Primitive Process>>primTerminate failed (0)

Chris Uppal-3
In reply to this post by Ian Bartholomew-21
Ian,

> 2) Delete the SerialChat class methods #initialize and #uninitialize

Do you have an idea why (2) is necessary ?

I have several tools which can either be standalone .exes or tools added to the
Dolphin system.  I use code not unlike yours in my Shell classes'
#intialize/#uninitialize methods.  So far (up to D5) this has all worked
without problems; should I expect them as/when I move properly to D6 ?

    -- chris


Reply | Threaded
Open this post in threaded view
|

Re: Primitive Process>>primTerminate failed (0)

Chris Uppal-3
In reply to this post by Ian Bartholomew-21
Ian,

> Just FYI.

Thank you.  Please ignore the post I've just sent asking for clarification ;-)


> Unfortunately, in this case, the methods that we all suggested to Joseph
> for tracking down the problem wouldn't have helped much. ;-(

Except one:

Chris Uppal wrote:
> BTW, having a dependency on the dev-sys packages is sometimes a symptom of
> something that's more deeply wrong.  It's usually worth tracking down
> exactly /why/ you have the dependency, even if you don't take the time to
> fix it straight-away.

<huge *smug* grin>

    -- chris


Reply | Threaded
Open this post in threaded view
|

Re: Primitive Process>>primTerminate failed (0)

Ian Bartholomew-21
In reply to this post by Chris Uppal-3
Chris,

> Do you have an idea why (2) is necessary ?

No, sorry - it was just an assumption.  I thought it might be the cause
of the #primTerminate error that Joseph was seeing (a registered window
that wasn't available when the deployed app closed) but I didn't check
anything.

I just tried a deployment (under 6.0.2) where the only change I made was
to override the class side #defaultModel method - the deployed app
didn't run.

I'll have a deeper look a bit later, it looks like 6.0.2 is going to
need a bit of a change to the goodies...

--
Ian

Use the Reply-To address to contact me (limited validity).
Mail sent to the From address is ignored.


Reply | Threaded
Open this post in threaded view
|

Re: Primitive Process>>primTerminate failed (0)

Udo Schneider
In reply to this post by Joseph Frippiat
Joseph Frippiat wrote:
  > onViewOpened
>     super onViewOpened.
>     self beFinalizable.
>     (self view viewNamed: 'status') model: (status := '  Not connected'
> asValue).
>     comPort
>         list: self comPorts;
>         selection: self comPorts first

On thing that springs into my mind is finalization. I once had a similar
problem where an finalizable instance got finalized in the running app
... but the things it tried to access where stripped out.

This can happen if your instance is somehow referred by the IDE with all
classes. During image stripping the only instance referencing your
instance gets nilled (or stripped out) so that your instance is still
part of the image.

Once you start the application and a GC occurs .... BOOOOOM!.

Add tracing methods to you realize/finalize methods and try to determine
if your deployed app finalzes and instance it didn't realize.

Does this make sense? :-)

CU,

Udo


Reply | Threaded
Open this post in threaded view
|

Re: Primitive Process>>primTerminate failed (0)

Udo Schneider
In reply to this post by Schwab,Wilhelm K
Bill Schwab wrote:
> Use control-alt-del and then lock the computer; you will need to enter a
Windows Key + N is even faster :-)

> Just a hunch, but look at the process browser to see if you have any
I would recommend SysInternals Process Explorer here. It can replace the
bultin Windows Taskmanager and display way more information.

CU,

Udo


Reply | Threaded
Open this post in threaded view
|

Re: Primitive Process>>primTerminate failed (0)

Udo Schneider
Udo Schneider wrote:
> Windows Key + N is even faster :-)
Should have been "Windows Key + L" .... like "Lock" ;-)

CU,

Udo


Reply | Threaded
Open this post in threaded view
|

Re: Primitive Process>>primTerminate failed (0)

Joseph Frippiat-2
In reply to this post by Ian Bartholomew-21
I downloaded the patch level 2 and all works fine now :-) .  I was able
to deploy my application four times in a row ...  No more message box
and no more starting delay.

Now I will track the dependencies to remove the part of the development
system that my application distributes.

Thanks to everyone, I learned a lot about the debugging tools.

Joseph


Reply | Threaded
Open this post in threaded view
|

Re: Primitive Process>>primTerminate failed (0)

Udo Schneider
Joseph Frippiat wrote:
> I downloaded the patch level 2 and all works fine now :-) .  I was able
> to deploy my application four times in a row ...  No more message box
> and no more starting delay.
Now that's strange .... quick question. Did you deploy your application
from your regular image or from a clean base image?

I allways do all the development in my working image. If I need to
deploy an app I'll save the packages, fire up a clean image, import the
packages and deploy. This is to make sure that the packages really
contain all the stuff and do not have some hidden depedency on code or
change methods in the base image.

> Thanks to everyone, I learned a lot about the debugging tools.
Debugging is one of the things I really really hate .... but if I need
to it's good to know the tools to do so :-)

CU,

Udo


Reply | Threaded
Open this post in threaded view
|

Re: Primitive Process>>primTerminate failed (0)

Joseph Frippiat-2
In reply to this post by Chris Uppal-3
Chris Uppal a écrit :

> BTW, having a dependency on the dev-sys packages is sometimes a symptom of
> something that's more deeply wrong.  It's usually worth tracking down exactly
> /why/ you have the dependency, even if you don't take the time to fix it
> straight-away.

I found the dependency: my application uses IDB Serial which is
dependent from IDB Common which seems to be part of the development
system.  Do I transgress the law :-) ?

Thanks,

Joseph


Reply | Threaded
Open this post in threaded view
|

Re: Primitive Process>>primTerminate failed (0)

Joseph Frippiat-2
In reply to this post by Ian Bartholomew-21
Ian Bartholomew a écrit :

> 1) Load the package into a clean image
> 2) Delete the SerialChat class methods #initialize and #uninitialize
> 3) Move the SerialChat class to become a subclass of Shell
> 4) Save the package
> 5) Exit the image without saving
> 6) Restart the image and reload the package

I already did that in a different way, starting with Dolphin 5 from
Bitwise Magazine and your goodies for Dolphin 5:
1) I renamed SerialChat to VirtualPrinter.
2) I moved VirtualPrinter in a new package.
3) I made VirtualPrinter a subclass of the Shell class.
4) I saved the package.
5) I quitted without saving the image.
6) I installed Dolphin X6 Pro
7) I created a new clean image.
8) I loaded the IDB Serial package.
9) I loaded my package.
10) I modified VirtualPrinter to use 8 data bits instead of 7 (by
creating KPSSerialIO as a subclass of SerialIO (and creating also a
dependency from de development system ...) and modifying the initDCB
method if I remember well.
11) I implemented a little communication protocol to talk to an external PLC
12) ...

So my application is a derivative of SerialChat for Dolphin 5 (not 6:
there are little differences in the default view and also in some methods).

Each time, for the deployment, I restarted from a clean fresh and
patched image.

This afternoon, when I was creating a new clean image, I discovered the
patch level 2.

I created a clean image with the patch level 2 (downloading, installing,
...) and now the deployment seems to work.  I tried it several times and
it worked.  It's perhaps a coincidence but ...

Now I have a sexy little program that will be used by the maintenance
guys for the machines that the company, for which I work, builds.

For the next application I will try to anticipate the possible
deployments problems.

Thanks,

Joseph


Reply | Threaded
Open this post in threaded view
|

Re: Primitive Process>>primTerminate failed (0)

Schwab,Wilhelm K
In reply to this post by Udo Schneider
Udo Schneider wrote:
> Bill Schwab wrote:
>
>> Use control-alt-del and then lock the computer; you will need to enter a
>
> Windows Key + N is even faster :-)

Didn't know that one - thanks!


>> Just a hunch, but look at the process browser to see if you have any
>
> I would recommend SysInternals Process Explorer here. It can replace the
> bultin Windows Taskmanager and display way more information.

Wrong machine - I'm thinking of stuff running on the Dolphin VM :)  I
know the tool though, and your recommendation is well taken.

Have a good one,

Bill


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


Reply | Threaded
Open this post in threaded view
|

Re: Primitive Process>>primTerminate failed (0)

Udo Schneider
Bill Schwab wrote:
>> Windows Key + N is even faster :-)
> Didn't know that one - thanks!
I hope you got the correction "Windows Key + L".

BTW: "Windows Key + M" is usefull as well ... it minimizes all windows
(to access the desktop quickly).

CU,

Udo


12