D6 Error opening image

Hi,

I get the error below when starting an image (by double-clicking on the
.img file) (The image, unfortunately, doesn't open ... I just get the
error below in the .ERRORS file).

Does anybody have any opinions on whether D6 is more susceptible to
saving a bad image than D5?

I can't recall this ever happening to me in D5, and that includes an
image I used and saved daily for about 3 years.

I had done no view development in this image, and the only views that I
had used in it were the development tools. It might have had a dead
process saved into the image ... not sure if this is relevant.

BTW: Thank you Ian for the ChunkBrowser which got me (once again) out
of my mess!

Steve
--
Steve Waring


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

0:01:21 AM, 3/20/2006: Dolphin.exe caused an unhandled Win32 Exception
C0000005
at 10001242 in module 10000000 (C:\Program Files\Object Arts\Dolphin
Smalltalk 6.0\DolphinVM006.dll)

*----> Exception Parameters <----*
00000000
980B0A35

*----> CPU Context for thread 0x494 <----*
EAX = 0000069B EBX = 0B0A31A4 ECX = 0B0A319D
ESI = 980B0A31 EDI = 0B0A319D EIP = 10001242
ESP = 00C0FDD0 EBP = 10050010 EFL = 00010287
CS = 001B SS = 0023 DS = 0023
ES = 0023 FS = 003B GS = 0000

*----> VM Context <----*
Process: {0AF30004:size 380009 words, suspended frame 0B0A30D1,
priority 1, callbacks 0
last failure 134381576:nil, FPE mask 3, thread nil}
Active Method: MemoryManager>>primCollectGarbage:
IP: 0A898C10 (0)
SP: 0B0A31C0
BP: 0B0A31A4 (379993)
ActiveFrame: {0B0A31A8: cf 0B0A318D, sp 00000000, bp 0B0A31A4, ip 0,
???92608718(MemoryManager)>>primCollectGarbage:}
        receiver: ***Bad OTE or Object: 0B0A3198(00000025)
        arg[0]: ***Freed object with Oop: 0B0A3178, class: ???92608562


New Method: MemoryManager>>primCollectGarbage:
Message Selector: primitiveFailed

*----> Stack Back Trace <----*
{0B0A31A8: cf 0B0A318D, sp 00000000, bp 0B0A31A4, ip 0,
???92608718(MemoryManager)>>primCollectGarbage:}
        receiver: ***Bad OTE or Object: 0B0A3198(00000025)
        arg[0]: ***Freed object with Oop: 0B0A3178, class: ???92608562

{0B0A318C: cf 0B0A3069, sp 0B0A319C, bp 0B0A3197, ip 19, [] in
***Unable to generate complete exception report (c0000005)

***** End of crash report *****

Steve,

Do you have any particular reason to suspect a dead process might be
lurking?  I ask because of some of the ways that comes about.

Did you do any external interface development?  If that dump means what
I think it means, one explanation is an overwrite of an object header,
and (as you probably know) can easily arise when external calls go
wrong, and will likely crash the system on the next GC.

D6 is new enough that I will not rule out a bug.  Even so, you might
consider RAM or disk problems.  I had a notebook drive that was almost
changing files as I was viewing them.  With hindsight, it first showed
itself in a network card settings corruption that I was able to
"correct" by uninstalling/reinstalling; this was a win98 machine, so it
was not shocking that something went wrong.  A month or two later, my
time based backup system tried to copy something that I had not altered,
and on looking at the data in the file, I found garbage where there was
once readable text, and it went downhill rapidly.  Immediately, I began
shopping for a replacement drive that fixed the problem.


> BTW: Thank you Ian for the ChunkBrowser which got me (once again) out
> of my mess!

Seconded: we need to erect a statue of Ian somewhere :)

Have a good one,

Bill


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

Hi Bill,

> Do you have any particular reason to suspect a
> dead process might be lurking?

I have a mild suspicion there may be a problem with saved processes,
but I don't know if it is related to this crash.

A couple of days ago I was deploying a different project. One of the
packages had a #publishedAspectsOfInstances method in it. If I
installed the packages in a fresh image, then immediately deployed
(then dismissed the MessageBox warning me about the development system
dependence), the resulting togo would immediately crash when run.

If I saved the image, removed the offending method, and then deployed
... no crash. I was able to repeat this a couple of times.

In the crashing case, it lead to a series of cascading errors as
reported in the "Dolphin X6 ToGo crash with dodgy .ERRORS file".
However the original error that triggered the cascading errors was:

10:50:54 AM, 3/19/2006: Primitive Process>>primTerminate failed (0)

I am fairly sure that process was not the main process, but was named
'Main'. Therefore my suspicion is it is the old main process forked
away by the MessageBox. I can repeat this, so I need to spend some time
experimenting with it and trying to reproduce a simple case.

> Did you do any external interface development?

No, but it uses Object Art's CDOIMessage and ADODB_Stream fairly
heavily. The bottom line is that it is an image I didn't even think
twice about saving. Nothing nasty or dangerous had happened in it to
make me pause and think whether I should abandon it instead of saving
it. However, I guess I don't have enough experience with D6 to know
what "nasty or dangerous" is yet.

> Even so, you might
> consider RAM or disk problems.

Yes, you are right. I think the drives are SMART drives so I will do a
diagnostic on them.

Thanks for your suggestions!
Steve
--
Steve Waring

Steve,

Especially considering the nil window handle problem you corrected (was
that you?<g>), the use of native vs. emulated modes, previous problems
with message boxes in deployed apps, etc., I'm suspicious that the
problem is external interfacing gone wrong rather than a defect in the
saved process.  In support of the latter, note how many other threads
work ok.  However, we could both be right in the sense that the problem
could be that the forked thread wakes up in the deployed image and does
something offensive that amounts to freeing memory it does not own, etc.
  Is there an overlapped call involved?  IIRC, the VM now has some
thread affinity for calls or at least contains some other changes to OS
thread management that might be causing trouble in this case.

At least those are things I would condider if I wrote something that
blew up like that.


IIRC, Dolphin will fork multiple main threads when displaying modal
dialogs, etc.


>>Did you do any external interface development?
>
>
> No, but it uses Object Art's CDOIMessage and ADODB_Stream fairly
> heavily. The bottom line is that it is an image I didn't even think
> twice about saving. Nothing nasty or dangerous had happened in it to
> make me pause and think whether I should abandon it instead of saving
> it. However, I guess I don't have enough experience with D6 to know
> what "nasty or dangerous" is yet.

Untested external interfacing will always qualify as dangerous - nail
and object header and it's over.  I suspect that presenter opening could
be made (perhaps only to some extent??) error safe, and maybe OA has
tried to do so in D6.  However, any time a presenter fails to open, I
get nervous.

There have been some changes to the type library analyzer, if only
cosmetic in the naming of selectors.  That bit me at one point, though
IIRC, it simply forced me to edit a few methods after recreating the
work in D5, because D5 created different names for the selectors.  In an
extreme case, it might interfere with overrides.  Things that have been
taken out of the auto-generated categories might be at risk.  I would
expect that they would break fairly obviously (calling things that no
longer exist), but it might be worth a quick scan just in case.

Good luck!!

Bill


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

Hi Bill,

Thanks for the suggestions!

>> A couple of days ago I was deploying a different project. One of the
>> packages had a #publishedAspectsOfInstances method in it. If I
>> installed the packages in a fresh image, then immediately deployed
>> (then dismissed the MessageBox warning me about the development system
>> dependence), the resulting togo would immediately crash when run.

>> If I saved the image, removed the offending method, and then deployed
>> ... no crash. I was able to repeat this a couple of times.

I did find a recent thread: "Primitive Process>>primTerminate failed
(0)" that described something very similar to what I was/am seeing.
Like what was described in that thread, if I wait around, eventually
the app will show itself.

DebugView shows:

[3332] WARNING: Ignored interrupt 18 to terminated process a
Process('Main' base 09480000 frame=nil)
[3332] Dolphin: Writing dump to ...
[3332] WARNING: No processes are Ready to run

I know it sounds unbelievable, but I have since found that the only
difference between getting the "Primitive Process>>primTerminate failed
(0)" error and not getting it is:
 - Case 1/ Install the packages and then deploy the executable
immediately, results in  the "primTerminate failed " error.
 - Case 2/ Install the packages, then save/exit/restart the image and
then deploy ... no error.

I compared the deployment manifests with an xml comparison tool and the
only significant differences I could find were:

  - Togo was 100kb larger in Case 1/  than Case 2/
  - ComDlgLibrary had 0 instances in Case 1/ , but had 1 instance in
Case 2/
  - ShellLibrary had 1 instance in Case 1/ , but had 0 instances in
Case 2/
  - Case 1/ had an extra 11 ExternalHandle instances which is explained
by 11 extra Icon instances
  - The ImageStripperProgress class was stripped in Case 1/ but not
Case 2/

There were a few other changes in the number of strings/symbols etc,
but they looked like they were as a result of the extra class being
stripped. What was reported in the respective manifests did not, in my
mind, add up to a 100kb difference between the two togos.

FWIW: I have not been able to reproduce this with a simple package, In
any case, I have a work around and I typically
install/save/exit/restart when deploying anyway because it usually cuts
5 to 10kb off the size of the togo ... however I have never seen a drop
of 100kb before.

Steve
--
Steve Waring

Steve,

>   - Togo was 100kb larger in Case 1/  than Case 2/
>   - ComDlgLibrary had 0 instances in Case 1/ , but had 1 instance in
> Case 2/
>   - ShellLibrary had 1 instance in Case 1/ , but had 0 instances in
> Case 2/
>   - Case 1/ had an extra 11 ExternalHandle instances which is explained
> by 11 extra Icon instances
>   - The ImageStripperProgress class was stripped in Case 1/ but not
> Case 2/

That's very odd!

(I don't have anything /constructive/ to add.  Sorry ;-)

    -- chris

Steve,

> I did find a recent thread: "Primitive Process>>primTerminate failed
> (0)" that described something very similar to what I was/am seeing.
> Like what was described in that thread, if I wait around, eventually
> the app will show itself.

Going way back, I had to hack the idle loop for benefit of COM apps that
would stall in absence of user input.  When I hear of delays followed by
an app starting, I get flashbacks.


> DebugView shows:
>
> [3332] WARNING: Ignored interrupt 18 to terminated process a
> Process('Main' base 09480000 frame=nil)
> [3332] Dolphin: Writing dump to ...
> [3332] WARNING: No processes are Ready to run

Is that "the" main process, or another that was is having trouble going
away?


> I know it sounds unbelievable, but I have since found that the only
> difference between getting the "Primitive Process>>primTerminate failed
> (0)" error and not getting it is:
>  - Case 1/ Install the packages and then deploy the executable
> immediately, results in  the "primTerminate failed " error.
>  - Case 2/ Install the packages, then save/exit/restart the image and
> then deploy ... no error.

I wouldn't predict it, but it's not really shocking, especially if the
loading and deploying is scripted vs. user driven.  Have you tried
adding a few explicit #collectGarbage and #administerLastRites sends?


Interesting.  There are things that are cleared on startup, though I
would expect most of this stuff to be recreated when the IDE reloads.


> There were a few other changes in the number of strings/symbols etc,
> but they looked like they were as a result of the extra class being
> stripped. What was reported in the respective manifests did not, in my
> mind, add up to a 100kb difference between the two togos.

I frequently see changes of 100k or so in normal use.  It could simply
be the fortunes of dynamic memory management - or does Dolphin trim the
excess when it saves such that that makes no sense???


> FWIW: I have not been able to reproduce this with a simple package, In
> any case, I have a work around and I typically
> install/save/exit/restart when deploying anyway because it usually cuts
> 5 to 10kb off the size of the togo ... however I have never seen a drop
> of 100kb before.

I like to get an image running nicely, test passing, etc., and then
deploy from it.  I know many people like to deploy from a clean image,
but even if I were to do that, I would still get everying loaded and
save before deploying.  To do otherwise could be quite slow.  Just
restarting/stripping from a batch file takes 30 minutes for everything
that I deploy.

Have a good one,

Bill

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

Hi Bill,

> > [3332] WARNING: Ignored interrupt 18 to terminated process a
> > Process('Main' base 09480000 frame=nil)
> > [3332] Dolphin: Writing dump to ...
> > [3332] WARNING: No processes are Ready to run
>
> Is that "the" main process, or another that was is having trouble going
> away?

I believe it is the main process.

See the badly named "DebugView" thread. I got similar warnings
deploying the OA "Simple Web Browser" sample ... which has no message
boxes during deployment.

I have not tried this on another machine, nor with other OA samples,
but I am guessing (hoping!) these warnings are related to my problem.

> loading and deploying is scripted vs. user driven.

Deployment was user driven (right click on package, then "Deploy
Executable").

> Interesting.  There are things that are cleared on startup, though I
> would expect most of this stuff to be recreated when the IDE reloads.

I think that resources like icons are lazily created, so saving the
image and reloading with as few IDE toolwindows open, cut down on the
number of Icon instances in a deployed image (at least in D5).

> I like to get an image running nicely, test passing, etc., and then
> deploy from it.  I know many people like to deploy from a clean image,
> but even if I were to do that, I would still get everying loaded and
> save before deploying restarting/stripping

Yes, personally I feel that a save/restart gives a cleaner deploy.

> from a batch file takes 30 minutes for everything
> that I deploy.

Wow ... that is a lot of deploying!

Steve
--
Steve Waring

[hidden email] wrote:
> I get the error below when starting an image (by double-clicking on the
> .img file) (The image, unfortunately, doesn't open ... I just get the
> error below in the .ERRORS file).


I got an error opening the image, because I had the setting

  Control Panel -> System -> Advanced -> Performance -> Data Execution
Prevention

set to "Turn on DEP for ALL programs ..."

I'm running on AMD64 which provides hardware-based DEP.

Yours may be a different problem. But I'm curious as to
why the DEP should fail Dolphin.

-Panu Viljamaa

Hi Panu,

> Yours may be a different problem. But I'm curious as to
> why the DEP should fail Dolphin.

This is reported to be fixed in Dolphin 6.02. See:

"No Execution Incompatibility of D5 and D6 + Workaround"
http://groups.google.com/group/comp.lang.smalltalk.dolphin/browse_frm/thread/b9361e16e42bb822/

What version of Dolphin are you using? If you are interested in a fix
for D5, see:

"Help raise $800 for a D5 fix"
http://groups.google.com/group/comp.lang.smalltalk.dolphin/browse_frm/thread/f86961e2033caa81/011e18112befc149
 

Steve
--
Steve Waring

Steve Alan Waring wrote:

> This is reported to be fixed in Dolphin 6.02.

Good. The problem happened before it.
I haven't yet tested with the new patch,
but soon will, turn the DEP back on. Thanks.

- Panu Viljamaa