Full VMLibrary>>crashDump:

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

Full VMLibrary>>crashDump:

Carsten Haerle
I tried to track down the deployment problems where the image crashes and
must exit during deployment. When I look at the crash dump file there is
only a partial strack trace (some lines in the middle are left out). Is it
possible to configure the VM to get a full crash dump? My crash dump looks
like this:

[0C7F09C0: 607]-->104826092
[0C7F09BC: 606]-->90
[0C7F09B8: 605]-->104826050
[0C7F09B4: 604]-->1
...
<452 slots omitted>
...
[0C7F02A0: 151]-->[] @ 15 in ExceptionHandlerAbstract>>try:
[0C7F029C: 150]-->a MethodContext for: ExceptionHandlerAbstract>>try: frame:
c7f028d receiver: a ExceptionHandler
[0C7F0298: 149]-->ExceptionHandlerAbstract>>try:
[0C7F0294: 148]-->104825166
[0C7F0290: 147]-->42
[0C7F028C: 146]-->104825148
[0C7F0288: 145]-->104825144
[0C7F0284: 144]-->BlockClosure>>on:do:

I still search for the problem why I cannot deploy "hello world" in my
image. It seems that the stripper tries to remove redundant packages and
somehow starts deserializing view resources and this failes:

[0C7F0AD0: 675]-->Object>>doesNotUnderstand:
[0C7F0ACC: 674]-->104826218
[0C7F0AC8: 673]-->8
[0C7F0AC4: 672]-->104826196
[0C7F0AC0: 671]-->Message selector: #@ arguments: a Array
[0C7F0ABC: 670]-->0
[0C7F0AB8: 669]-->104826192
[0C7F0AB4: 668]-->MoenTreeNode>>setObject:parent:
[0C7F0AB0: 667]-->104826204
[0C7F0AAC: 666]-->10
[0C7F0AA8: 665]-->104826180
[0C7F0AA4: 664]-->nil
[0C7F0AA0: 663]-->nil
[0C7F0A9C: 662]-->a MoenTreeNode
[0C7F0A98: 661]-->104826176
[0C7F0A94: 660]-->MoenTreeNode class>>object:parent:
[0C7F0A90: 659]-->104826188
[0C7F0A8C: 658]-->9
[0C7F0A88: 657]-->104826164
[0C7F0A84: 656]-->nil
[0C7F0A80: 655]-->nil
[0C7F0A7C: 654]-->MoenTreeNode
[0C7F0A78: 653]-->a MethodContext for: MoenTreeView
class>>stbConvertFromVersion10: frame: c7f0a69 receiver: MoenTreeView
[0C7F0A74: 652]-->MoenTreeView class>>stbConvertFromVersion10:
[0C7F0A70: 651]-->104826172
[0C7F0A6C: 650]-->8
[0C7F0A68: 649]-->104826154
[0C7F0A64: 648]-->104826148
[0C7F0A60: 647]-->MoenTreeView class>>stbConvert:fromVersion:

Regards

Carsten


Reply | Threaded
Open this post in threaded view
|

Re: Full VMLibrary>>crashDump:

Blair McGlashan-3
"Carsten Haerle" <[hidden email]> wrote in message
news:4149610b$0$19002$[hidden email]...
>I tried to track down the deployment problems where the image crashes and
> must exit during deployment. When I look at the crash dump file there is
> only a partial strack trace (some lines in the middle are left out). Is it
> possible to configure the VM to get a full crash dump? ...

You can run the following script to create the necessary registry entries.

((RegKey localMachineRoot
 createKey: 'Software\Object Arts\Dolphin Smalltalk 5.0\CrashDump')
subValues)
 at: 'StackDepth' put: 2 ** 32 - 1;
 at: 'WalkbackDepth' put: 2 ** 32 - 1

> ...
> I still search for the problem why I cannot deploy "hello world" in my
> image. It seems that the stripper tries to remove redundant packages and
> somehow starts deserializing view resources and this failes:
> ...
> [0C7F0AD0: 675]-->Object>>doesNotUnderstand:
> [0C7F0ACC: 674]-->104826218
> [0C7F0AC8: 673]-->8
> [0C7F0AC4: 672]-->104826196
> [0C7F0AC0: 671]-->Message selector: #@ arguments: a Array
>...
> [0C7F0A78: 653]-->a MethodContext for: MoenTreeView
> class>>stbConvertFromVersion10: frame: c7f0a69 receiver: MoenTreeView
> [0C7F0A74: 652]-->MoenTreeView class>>stbConvertFromVersion10:
>...

The Number>>@ method must have been removed already. I don't quite
understand why that would have happened at the stage of removing redundant
packages, since it is in the base (Dolphin) package, and thus won't be
removed unless and until the reference walking algorithm detects that it is
no longer reachable along a reference chain. A possible explanation would be
explicit removal of the method in the pre-strip script, but although the
Point>>@ method is deliberately removed by the Hello World pre-strip script
(to allow Point3D to be stripped), I don't think that Number>>@ is similarly
removed.

It seems that one of your view resources contains an old-format
MoenTreeView, so you may need to upgrade so that it does not need to go
through the conversion process when accessed during deployment (load it into
the ViewComposer and resave).

Regards

Blair