Probably just growing pains???

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

Probably just growing pains???

Bill Schwab-2
Hi Blair,

I managed to deploy a COM DLL, and now I'm trying to prove that it works.  I
noticed the dump below after some fumbling with regsvr32 and the type
library analyzer.  Is this telling me that I let something essential get
stripped, or is it simply telling me that I don't know how to register a DLL
:)

Have a good one,

Bill


************************** Dolphin Virtual Machine Dump Report
***************************

14:42:23 PM, 2/28/02: AXTypeLibraryAnalyzer class does not understand
#onStartup

*----> VM Context <----*
Process: {079A0004:suspended frame 079A0349, priority 8, callbacks 0
last failure 2:nil, FPE mask 3, thread nil}
Active Method: AXDllSessionManager>>logError:
IP: 07968B0F (15)
SP: 079A0458
BP: 079A0430 (251)
ActiveFrame: {079A0434: cf 079A0419, sp 079A0448, bp 079A0430, ip 5,
AXDllSessionManager>>logError:}

New Method: VMLibrary>>dump:path:stackDepth:walkbackDepth:
Message Selector: #dump:path:stackDepth:walkbackDepth:

*----> Stack <----*
[079A0458: 261]-->30
[079A0454: 260]-->60
[079A0450: 259]-->nil
[079A044C: 258]-->'AXTypeLibraryAnalyzer class does not understand
#onStartup'
[079A0448: 257]-->a VMLibrary
[079A0444: 256]-->63767064
[079A0440: 255]-->AXDllSessionManager>>logError:
[079A043C: 254]-->63767076
[079A0438: 253]-->8
[079A0434: 252]-->63767052
[079A0430: 251]-->a MessageNotUnderstood
[079A042C: 250]-->a AXDllSessionManager
[079A0428: 249]-->63767050
[079A0424: 248]-->AXDllSessionManager>>unhandledException:
[079A0420: 247]-->63767060
[079A041C: 246]-->7
[079A0418: 245]-->63767038
[079A0414: 244]-->a MessageNotUnderstood
[079A0410: 243]-->a AXDllSessionManager
[079A040C: 242]-->63767036
[079A0408: 241]-->SessionManager>>onUnhandledError:
[079A0404: 240]-->63767046
[079A0400: 239]-->3
[079A03FC: 238]-->63767024
[079A03F8: 237]-->a MessageNotUnderstood
[079A03F4: 236]-->a AXDllSessionManager
[079A03F0: 235]-->63767024
[079A03EC: 234]-->Error>>defaultAction
[079A03E8: 233]-->63767032
[079A03E4: 232]-->8
...
<200 slots omitted>
...
[079A00C0: 31]-->a MethodContext
[079A00BC: 30]-->BlockClosure>>ifCurtailed:
[079A00B8: 29]-->63766628
[079A00B4: 28]-->20
[079A00B0: 27]-->63766606
[079A00AC: 26]-->63766602
[079A00A8: 25]-->BlockClosure>>ensure:
[079A00A4: 24]-->63766614
[079A00A0: 23]-->7
[079A009C: 22]-->63766590
[079A0098: 21]-->nil
[079A0094: 20]-->[] @ 34 in ExceptionHandlerAbstract>>try:
[079A0090: 19]-->[] @ 15 in ExceptionHandlerAbstract>>try:
[079A008C: 18]-->a MethodContext
[079A0088: 17]-->ExceptionHandlerAbstract>>try:
[079A0084: 16]-->63766598
[079A0080: 15]-->42
[079A007C: 14]-->63766580
[079A0078: 13]-->63766576
[079A0074: 12]-->BlockClosure>>on:do:
[079A0070: 11]-->63766588
[079A006C: 10]-->10
[079A0068: 9]-->63766564
[079A0064: 8]-->[] @ 12 in BlockClosure>>newProcess
[079A0060: 7]-->ProcessTermination
[079A005C: 6]-->[] @ 5 in InputState>>forkMain
[079A0058: 5]-->[] @ 6 in BlockClosure>>newProcess
[079A0054: 4]-->BlockClosure>>newProcess
[079A0050: 3]-->63766572
[079A004C: 2]-->20
[079A0048: 1]-->0
<Bottom of stack>

*----> Stack Back Trace <----*
{079A0434: cf 079A0419, sp 079A0448, bp 079A0430, ip 5,
AXDllSessionManager>>logError:}
{079A0418: cf 079A03FD, sp 079A0428, bp 079A0414, ip 4,
AXDllSessionManager>>unhandledException:}
{079A03FC: cf 079A03E1, sp 079A040C, bp 079A03F8, ip 4,
AXDllSessionManager(SessionManager)>>onUnhandledError:}
{079A03E0: cf 079A03C9, sp 079A03F0, bp 079A03E0, ip 5,
MessageNotUnderstood(Error)>>defaultAction}
{079A03C8: cf 079A03B5, sp 079A03D8, bp 07963AC8, ip 57,
MessageNotUnderstood(Exception)>>_propagateFrom:}
{079A03B4: cf 079A0399, sp 079A03C4, bp 079A03B0, ip 6,
MessageNotUnderstood(Exception)>>_propagate}
{079A0398: cf 079A0381, sp 079A03A8, bp 079A0398, ip 12,
MessageNotUnderstood(Exception)>>signal}
{079A0380: cf 079A0361, sp 079A0390, bp 079A0378, ip 13,
MessageNotUnderstood class>>receiver:message:}
{079A0360: cf 079A0345, sp 079A0370, bp 079A035C, ip 5,
AXTypeLibraryAnalyzer class(Object)>>doesNotUnderstand:}
{079A0344: cf 079A032D, sp 079A0354, bp 079A0344, ip 5,
EventMessageSend(MessageSend)>>value}
{079A032C: cf 079A0311, sp 079A033C, bp 07963A90, ip 9, [] in
EventMessageSequence(MessageSequenceAbstract)>>value}
{079A0310: cf 079A02E5, sp 079A0328, bp 079A02FC, ip 40,
EventMessageSequence>>messagesDo:}
{079A02E4: cf 079A02D1, sp 079A02F4, bp 07963A90, ip 13,
EventMessageSequence(MessageSequenceAbstract)>>value}
{079A02D0: cf 079A02BD, sp 079A02E0, bp 07963A58, ip 10,
EventsCollection>>triggerEvent:}
{079A02BC: cf 079A02A1, sp 079A02CC, bp 079A02B8, ip 5,
AXDllSessionManager(Object)>>trigger:}
{079A02A0: cf 079A0285, sp 079A02B0, bp 079638D0, ip 58, [] in
AXDllSessionManager(SessionManager)>>onStartup:}
{079A0284: cf 079A0271, sp 079A029C, bp 07963A20, ip 17,
BlockClosure>>ifCurtailed:}
{079A0270: cf 079A0251, sp 079A0280, bp 079A0268, ip 4,
BlockClosure>>ensure:}
{079A0250: cf 079A0235, sp 079A0260, bp 079638D0, ip 67, [] in
AXDllSessionManager(SessionManager)>>onStartup:}
{079A0234: cf 079A0221, sp 079A024C, bp 07963908, ip 17,
BlockClosure>>ifCurtailed:}
{079A0220: cf 079A0201, sp 079A0230, bp 079A0218, ip 4,
BlockClosure>>ensure:}
{079A0200: cf 079A01ED, sp 079A0210, bp 079638D0, ip 86,
AXDllSessionManager(SessionManager)>>onStartup:}
{079A01EC: cf 079A01D1, sp 079A01FC, bp 079A01E8, ip 11,
ProcessorScheduler>>onStartup:}
{079A01D0: cf 079A01B5, sp 079A01E0, bp 07963860, ip 11, [] in
ProcessorScheduler>>vmi:list:no:with:}
{079A01B4: cf 079A01A1, sp 079A01CC, bp 07963898, ip 17,
BlockClosure>>ifCurtailed:}
{079A01A0: cf 079A017D, sp 079A01B0, bp 07963860, ip 20,
ProcessorScheduler>>vmi:list:no:with:}
{079A017C: cf 079A0159, sp 079A019C, bp 079A0170, ip 47,
AXDllImageStripper(ImageStripper)>>snapshot:}
{079A0158: cf 079A0145, sp 079A0168, bp 07969970, ip 14,
AXDllImageStripper(ImageStripper)>>saveExecutable:}
{079A0144: cf 079A012D, sp 079A0154, bp 079A0144, ip 5, MessageSend>>value}
{079A012C: cf 079A0109, sp 079A013C, bp 079A0120, ip 32,
InputState>>loopWhile:}
<...more...>

***** End of dump *****



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


Reply | Threaded
Open this post in threaded view
|

Re: Probably just growing pains???

Bill Schwab-2
Hi Blair,

A little more info: the new DLL is resisting a little.  Most of the slick
tools that I have installed don't see it; I haven't yet determined whether
that's because it's not registered correctly or because it's not in the
categories the tools expect.  I got D4 to generate its interface and got to
the point of being told that there was an exception when invoking a method.
The interesting part is that after the exception occurs, I can no longer
instantiate the control via ISomeInterfaceItUnderstands new, where I could
before the exception.  I've seen that twice in two different Dolphin
sessions trying to talk to it.

I couldn't set the type library path in the package, and IIRC, the type
library wouldn't be registered anyway.  I'm assuming that I want to register
the type library and then register the DLL???

A bug, I think: it looks like the crash-dump based ERRORS file for the
control is truncating/replacing the file rather than appending.

Have a good one,

Bill

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


Reply | Threaded
Open this post in threaded view
|

Re: Probably just growing pains???

Blair McGlashan
In reply to this post by Bill Schwab-2
"Bill Schwab" <[hidden email]> wrote in message
news:[hidden email]...
> Hi Blair,
>
> I managed to deploy a COM DLL, and now I'm trying to prove that it works.
I
> noticed the dump below after some fumbling with regsvr32 and the type
> library analyzer.  Is this telling me that I let something essential get
> stripped, or is it simply telling me that I don't know how to register a
DLL
> :)
> ....
> 14:42:23 PM, 2/28/02: AXTypeLibraryAnalyzer class does not understand
> #onStartup
>

That is odd. I would not have expected AXTypeLibraryAnalyzer
class>>onStartup to have been stripped. Although the method itself is not
specifically preserved in any way, #onStartup (the message) is explicitly
sent from a number of methods that are integral to the startup (e.g.
SessionManager>>comStartup) and would definitely not have been stripped or
your session would not have proceeded as far as it has: #comStartup is part
of #secondaryStartup, which is run before the #sessionStarted event is
triggered.

Can you send me the stripper log?

Regards

Blair


Reply | Threaded
Open this post in threaded view
|

Re: Probably just growing pains???

Blair McGlashan
In reply to this post by Bill Schwab-2
"Bill Schwab" <[hidden email]> wrote in message
news:[hidden email]...
>
> A little more info: the new DLL is resisting a little.  Most of the slick
> tools that I have installed don't see it; I haven't yet determined whether
> that's because it's not registered correctly or because it's not in the
> categories the tools expect.

D5 COM DLLs definitely don't register their embedded type library correctly.
Otherwise the registration is just that for a standard non-visual
component - i.e. there will be no category registrations at all. You should
still be able to see the component in VB and OLEVIEW (for example).

>...I got D4 to generate its interface and got to
> the point of being told that there was an exception when invoking a
method.
> The interesting part is that after the exception occurs, I can no longer
> instantiate the control via ISomeInterfaceItUnderstands new, where I could
> before the exception.  I've seen that twice in two different Dolphin
> sessions trying to talk to it.

The first attempt will have loaded the DLL. On the second attempt it will
already be loaded. This could explain the different behaviour.

>
> I couldn't set the type library path in the package,

Any particular reason (apart from using Win9X as the development/deployment
system)?

>...and IIRC, the type
> library wouldn't be registered anyway.  I'm assuming that I want to
register
> the type library and then register the DLL???

Yes. It can be tricky to register a type library correctly. I find the best
way is to open it explicitly in a tool like VB, or Dolphin's own AX
Component Wizard.

>
> A bug, I think: it looks like the crash-dump based ERRORS file for the
> control is truncating/replacing the file rather than appending.

That's odd too. It shouldn't be any different than a normal dump, since the
code is the same. I'll look into it.

Regards

Blair


Reply | Threaded
Open this post in threaded view
|

Re: Probably just growing pains???

Bill Schwab
Blair,

A partial reply:

> > I couldn't set the type library path in the package,
>
> Any particular reason (apart from using Win9X as the
development/deployment
> system)?

Gottcha :)  This was on the NT4 box, rebooted just a few days ago.  I wasn't
sure what was happening, but, it wouldn't accept the type library path
name - I'd ok the dialog, but, nothing happened.  I'll play around with it
some more.

BTW, I did try to register and call the component on a 9x box, so that might
have caused some trouble.


> Yes. It can be tricky to register a type library correctly. I find the
best
> way is to open it explicitly in a tool like VB, or Dolphin's own AX
> Component Wizard.

That's what I finally did.  It's funny though, because I thought I read that
type libraries are self-registering??


> > A bug, I think: it looks like the crash-dump based ERRORS file for the
> > control is truncating/replacing the file rather than appending.
>
> That's odd too. It shouldn't be any different than a normal dump, since
the
> code is the same. I'll look into it.

If in fact my problem is one of too much stripping, it might have had a side
effect.  Still, I saw two different errors, and each time it was the only
one recorded in the file.

Have a good one,

Bill


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