| Title: | ObjectBroker Development - BEA Systems' CORBA |
| Notice: | See note 2 for kit locations; note 4 for training |
| Moderator: | RECV::GUMBEL d |
| Created: | Thu Dec 27 1990 |
| Last Modified: | Fri Jun 06 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 2482 |
| Total number of notes: | 13057 |
Help my DISCUS Client Crashes since OBB 2.7-11 CLD
Just after installing OBB 2.7-11 on OpenVMS 6.2, I've cleand up using
OBB$QUICK my FBE1:[STADELMANN.PROJ.OBB.DISCUS.AXP] Directory and
recreated all the Files using OBB$QUCIK.
A perfect error free build was the result.
The Discusserver is then launched and the discusclient as well.
It starts working but then (new with thos release of OBB) my
discusclient crashes.
LULU05::>run discusclient
***** Client Started Execution *****
***** Invoking CommonObjectObj->destroy *****
***** Invoking CommonObjectObj->open *****
***** Invoking CommonObjectObj->close *****
***** Invoking apObj->destroy *****
***** Invoking apObj->open *****
***** Invoking apObj->close *****
***** Invoking apObj->exchange *****
Stringified dataobject:
DEC::~100056465fc977a09a1000002102c10c60000000000021fc977a91b0000002102c10c60000
0000010100000121fc977a7ab0000002102c10c60000000001021fc977a7eb0000002102c10c6000
0000000121fc977a7fb0000002102c10c60000000000221fc977a80b0000002102c10c6000000000
0321fc977a96b0000002102c10c60000000000621fc977a98b0000002102c10c60000000000721fc
977a9bb0000002102c10c60000000000821fc977a9eb0000002102c10c60000000000921fc977a9f
b0000002102c10c60000000001021fc977a92b0000002102c10c60000000000421fc977a93b00000
02102c10c6000000000050000021fc977a91b0000002102c10c6000000020100010f7c0~~~~%|
***** Invoking apObj->convert *****
Stringified dataobject:
DEC::~100056465fc977a0aa1000002102c10c60000000000021fc977a91b0000002102c10c60000
0000010100000121fc977a7ab0000002102c10c60000000001021fc977a7eb0000002102c10c6000
0000000121fc977a7fb0000002102c10c60000000000221fc977a80b0000002102c10c6000000000
0321fc977a96b0000002102c10c60000000000621fc977a98b0000002102c10c60000000000721fc
977a9bb0000002102c10c60000000000821fc977a9eb0000002102c10c60000000000921fc977a9f
b0000002102c10c60000000001021fc977a92b0000002102c10c60000000000421fc977a93b00000
02102c10c6000000000050000021fc977a91b0000002102c10c6000000020100010f7c0~~~~%|
***** Invoking apObj->query *****
Stringified respondsedataobject:
DEC::~1000620b12b997ab5a7000002102c10c600000000019546869732069732044535f64745f5f
4f424a0021fc977a91b0000002102c10c600000000010100000121fc977a7ab0000002102c10c600
00000001021fc977a7eb0000002102c10c60000000000121fc977a7fb0000002102c10c600000000
00221fc977a80b0000002102c10c60000000000321fc977a96b0000002102c10c60000000000621f
c977a98b0000002102c10c60000000000721fc977a9bb0000002102c10c60000000000821fc977a9
eb0000002102c10c60000000000921fc977a9fb0000002102c10c60000000001021fc977a92b0000
002102c10c60000000000421fc977a93b0000002102c10c6000000000050000021fc977a91b00000
02102c10c6000000020100010f7c0~LULU05.zuo.dec.com~~~%|
Reference Data For The Above Object is:
This is DS_dt__OBJ
***** Invoking apObj->execute *****
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual
address=00000001, PC =002FE588, PS=0000001B
%TRACE-F-TRACEBACK, symbolic stack dump follows
Image Name Module Name Routine Name LineNo rel PC abs PC
OBB$SHR 0 000E4588 002FE588
DISCUSCLIENT 0 0005E2A4 0006E2A4
DISCUSCLIENT 0 0005F04C 0006F04C
OBB$SHR 0 000E2034 002FC034
OBB$SHR 0 000E4BF8 002FEBF8
OBB$SHR 0 000E52E0 002FF2E0
OBB$SHR 0 000E44D0 002FE4D0
OBB$SHR 0 000D0CB4 002EACB4
OBB$SHR 0 000CE1C0 002E81C0
OBB$SHR 0 0008F27C 002A927C
OBB$SHR 0 00072188 0028C188
DISCUSCLIENT 0 00061A74 00071A74
DISCUSCLIENT DISCUSSTUB DS::Stub_ap::ex 16213 00019DC8 00062A48
DISCUSCLIENT DISCUSCLIENT DSapexecute 13152 00004590 00044590
DISCUSCLIENT DISCUSCLIENT DS_apInvoke 12296 00001F8C 00041F8C
DISCUSCLIENT DISCUSCLIENT main 12142 00001834 00041834
DISCUSCLIENT DISCUSCLIENT __main 0 00000058 00040058
DISCUSCLIENT 0 0007C7D0 0008C7D0
0 83F8A170 83F8A170
LULU05::>show def
FBE1:[STADELMANN.PROJ.OBB.DISCUS.AXP]
LULU05::>
My DISCUS IDL file is at EMNTAL::DISCUS.IDL
Please take it and use it with OBB$QUICK BUILD.
And yes it is only the Client which crahses the server is still waiting
for more requests to come.
Sepp,
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 2428.1 | PTR 16-3-231 | REQUE::BOWER | Peter Bower, ObjectBroker | Mon Feb 03 1997 09:31 | 35 |
The problem is that the generated typecode for SeqObject is of type Object
instead of type dt. This causes problems when marshalling and
unmarshalling the argument. I think that this is also a bug in v2.7-10,
but I haven't checked. The workaround is to use the dt object instead
of the typedef in the operation definition. See the dif below.
I will enter a PTR on this to correct the code generation.
************
File $USER2:[BOWER.TEMP]DISCUS.IDL;21
84 // typedef dt SeqObject;
85
******
File $USER2:[BOWER.TEMP]DISCUS.SAV;1
83 typedef dt SeqObject;
84
************
************
File $USER2:[BOWER.TEMP]DISCUS.IDL;21
88 in dt inputdataobjects,
89 out dt outputdataobjects)
90 raises ( NOT_OPEN, UNSUPPORTED_LANGUAGE, SCRIPT_SYNTAX, UNKNOWN_OPERAND )
******
File $USER2:[BOWER.TEMP]DISCUS.SAV;1
87 in SeqObject inputdataobjects,
88 out SeqObject outputdataobjects)
89 raises ( NOT_OPEN, UNSUPPORTED_LANGUAGE, SCRIPT_SYNTAX, UNKNOWN_OPERAND )
************
Number of difference sections found: 3
Number of difference records found: 6
DIFFERENCES /IGNORE=()/MERGED=1/OUTPUT=$USER2:[BOWER.TEMP]DISCUS.DIF;1-
$USER2:[BOWER.TEMP]DISCUS.IDL;21-
$USER2:[BOWER.TEMP]DISCUS.SAV;1
| |||||
| 2428.2 | EMNTAL::STADELMANN | Sepp @ZUO 760-2609 | Tue Feb 04 1997 04:01 | 3 | |
Thank's Peter for QARing this.
It was working with 2.6 but I did not check it with 2.7-10.
Sepp,
| |||||