|
Hey, Anders !
Another customer of ours, VTKK has obviously got the same
problem which Ari mentioned about. I just got a log from
them, which starts when MRMEMO receives a 470 blocks long
message. It is obviously a message, that is too big !
The thing which a little confuses me is that the
first log is stamped at 21:30 and the stack dump log message
is stamped first at 23:33.
Is it the long message that causes the stack dump later or what ??
Here is the log from our customer:
Time: 1993-05-11 21:30:31.28; message from server MRMEMO1:
%MRMEMO-I-DISREJ, distribution rejected by MEMO system:
-MRMEMO-S-RCERRTXT_02, Memo is too big.
Time: 1993-05-11 23:33:30.76; message from server MRMEMO1:
%MRMEMO-F-MESSED, internal error in VAX MAILGATE for MEMO
%MRMEMO-W-TRACE, traceback forced from the Server Handler
-MRMEMO-I-FSM, idle, connected to MR and MEMO after message indicated in MR mailbox
-MRMEMO-I-RING, ring: '1A 1A 1A 1A 1A 1A 1A 1A 1A 19.', substates: 00000430
%TRACE-W-TRACEBACK, symbolic stack dump follows
module name routine name line rel PC abs PC
SRVLOG SRV$LOG_HANDLER 3943 000001C9 001E379D
----- above condition handler called with exception 0893803C:
%MRMEMO-F-MESSED, internal error in VAX MAILGATE for MEMO
----- end of exception message
ALLPAC ALL$PAC_END_LLIDF 2621 000000BA 001E94E0
ALLPAC ALL$PAC_DOC_UNIT 4247 0000007F 001EA59F
ALLPAC ALL$PAC_MSGITMLST_TO_GIUBUF 4394 000000BA 001EA6EF
SRVACT SRV$ACT_M 4773 000000B4 001EB220
SRVDSP SRV$DSP_FSM 3310 00000115 001E3299
SRVMMO SRV$MMO_ONE_LIFE 4376 000001EF 001E03BF
SRVMMO SRV$MMO_MAIN 4208 00000017 001E01C3
00239BAE 00239BAE
KOTERM KOTERM 804 00000039 002375A2
00239B89 00239B89
KODOC KODOC 1768 00000097 002347E4
00239B89 00239B89
0026537D 0026537D
ADA$ELAB_DDS ADA$ELAB_DDS 0000000E 001C0C0E
00239B89 00239B89
00239B89 00239B89
.
.
.
. The log continues here until:
.
.
.
.
.
Time: 1993-05-11 23:59:32.11; message from server MRMEMO1:
%MRMEMO-F-MESSED, internal error in VAX MAILGATE for MEMO
%MRMEMO-W-TRACE, traceback forced from the Server Handler
-MRMEMO-I-FSM, idle, connected to MR and MEMO after message indicated in MR mailbox
-MRMEMO-I-RING, ring: '52 19 ][ 4A 52 19 ][ 4A 52 19.', substates: 00000430
%TRACE-W-TRACEBACK, symbolic stack dump follows
module name routine name line rel PC abs PC
SRVLOG SRV$LOG_HANDLER 3943 000001C9 001E379D
----- above condition handler called with exception 0893803C:
%MRMEMO-F-MESSED, internal error in VAX MAILGATE for MEMO
----- end of exception message
ALLPAC ALL$PAC_END_LLIDF 2621 000000BA 001E94E0
ALLPAC ALL$PAC_DOC_UNIT 4247 0000007F 001EA59F
ALLPAC ALL$PAC_MSGITMLST_TO_GIUBUF 4394 000000BA 001EA6EF
SRVACT SRV$ACT_M 4773 000000B4 001EB220
SRVDSP SRV$DSP_FSM 3310 00000115 001E3299
SRVMMO SRV$MMO_ONE_LIFE 4376 000001EF 001E03BF
SRVMMO SRV$MMO_MAIN 4208 00000017 001E01C3
00239BAE 00239BAE
KOTERM KOTERM 804 00000039 002375A2
00239B89 00239B89
KODOC KODOC 1768 00000097 002347E4
00239B89 00239B89
0026537D 0026537D
ADA$ELAB_DDS ADA$ELAB_DDS 0000000E 001C0C0E
00239B89 00239B89
%SNA-I-UNBINDREC, UNBIND received from IBM application
Time: 1993-05-11 23:59:46.87; message from server MRMEMO1:
%MRMEMO-F-UNBIND, UNBIND request received from MEMO Gateway
%SNA-I-UNBINDREC, UNBIND received from IBM application
Time: 1993-05-12 00:00:55.62; message from server MRMEMO1:
%MRMEMO-F-UNBIND, UNBIND request received from MEMO Gateway
%SNA-I-UNBINDREC, UNBIND received from IBM application
Time: 1993-05-12 00:02:00.59; message from server MRMEMO1:
%MRMEMO-F-UNBIND, UNBIND request received from MEMO Gateway
.
.
.
. Again the log continues..
.
.
.
.
Time: 1993-05-12 01:04:57.99; message from server MRMEMO1:
%MRMEMO-F-UNBIND, UNBIND request received from MEMO Gateway
%SNA-I-UNBINDREC, UNBIND received from IBM application
Time: 1993-05-12 01:06:01.20; message from server MRMEMO1:
%MRMEMO-F-UNBIND, UNBIND request received from MEMO Gateway
%SYSTEM-F-ACCVIO, access violation, reason mask=01, virtual address=E2D440F8, PC=80000010, PSL=03C00004
Improperly handled condition, image exit forced.
Signal arguments Stack contents
Number = 00000005 80264240
Name = 0000000C 00000002
00000001 7FF1A090
E2D440F8 7FF1A078
80000010 00000004
03C00004 00030001
00000000
00010001
00000000
05000001
Register dump
R0 = 03C00000 R1 = E2D440F8 R2 = 00010001 R3 = 01455A7C
R4 = 0145812A R5 = 003171BC R6 = 01458132 R7 = 7FFEE1A8
R8 = 0030BFB4 R9 = 0030BFC0 R10= 0030BFBC R11= 003171BC
AP = 7FF1A02C FP = 7FF19FEC SP = 7FF1A068 PC = 80000010
PSL= 03C00004
%SYSTEM-F-ACCVIO, access violation, reason mask=01, virtual address=E2D440F8, PC=80000010, PSL=03C00004
Improperly handled condition, image exit forced.
Signal arguments Stack contents
Number = 00000005 80264240
Name = 0000000C 00000002
00000001 7FF19F90
E2D440F8 7FF19F78
80000010 00000004
03C00004 00030001
00000003
000323B0
00000015
03000001
Register dump
R0 = 03C00000 R1 = E2D440F8 R2 = 00010001 R3 = 01455A7C
R4 = 00010001 R5 = 003171BC R6 = 01458132 R7 = 7FFEE1A8
R8 = 0030BFB4 R9 = 0030BFC0 R10= 0030BFBC R11= 003171BC
AP = 7FF19F2C FP = 7FF19EEC SP = 7FF19F68 PC = 80000010
PSL= 03C00004
$! lis{ys khp 30.1.92 alkaa
$ show symbol $status
$STATUS == "%X1000000C"
$ reply/all/bell " ****** MRMEMO Server lopetti hommat ****** "
$! mail nl: system /subj="MRMEMO Server exit !!!!!!!!!!!!!!!!!!"
$! Kellonaika viestiin /tea 8.4.92
$ mail nl: system /subj="MRMEMO Server exit klo 01:06:07.06 !!!!!!!!"
$! lis{ys khp 30.1.92 loppuu
$ logout
MRMEMO job terminated at 12-MAY-1993 01:06:11.73
Accounting information:
Buffered I/O count: 153607 Peak working set size: 5774
Direct I/O count: 167363 Peak page file size: 44280
Page faults: 54645 Mounted volumes: 0
Charged CPU time: 0 01:40:18.63 Elapsed time: 1 18:04:20.79
|
| Some background on message size restrictions imposed by different
subsystems between MR and MEMO:
o MEMO has previously (before 3.1) handled a maximum message size
of 75 KB. Starting with 3.1, MEMO can handle up to 500 KB messages
(the upper limit is configurable, I believe).
o In the same time frame as the arrival of MEMO 3.1, a new MEMO/GWY
(1.1) was released, which can handle large (500 KB) messages.
o There has however been no new release of MEMO/MRGATE (still at 1.0) to
handle large messages.
o MRMEMO V2.1 can handle 500 KB messages.
So, the only component that has not been changed to match MEMOs ability
to handle large message is MEMO/MRGATE. This is a piece of Verimation
software so if you want to be able to pass larger messages through
MRMEMO, take the request to Verimation.
Now to the MRMEMO problems:
.2> Another customer of ours, VTKK has obviously got the same
.2> problem which Ari mentioned about. I just got a log from
.2> them, which starts when MRMEMO receives a 470 blocks long
.2> message. It is obviously a message, that is too big !
.2> The thing which a little confuses me is that the
.2> first log is stamped at 21:30 and the stack dump log message
.2> is stamped first at 23:33.
.2> Is it the long message that causes the stack dump later or what ??
.2>
.2> Here is the log from our customer:
.2>
.2> Time: 1993-05-11 21:30:31.28; message from server MRMEMO1:
.2> %MRMEMO-I-DISREJ, distribution rejected by MEMO system:
.2> -MRMEMO-S-RCERRTXT_02, Memo is too big.
.2> Time: 1993-05-11 23:33:30.76; message from server MRMEMO1:
.2> %MRMEMO-F-MESSED, internal error in VAX MAILGATE for MEMO
.
.
.
The error that occured 21:30 was caused by a message that is larger
than the 75 KB limit that is imposed by MEMO/MRGATE but smaller than
the MRMEMO 500 KB limit. The message has been formatted by MRMEMO and
shipped to the IBM, where something (probably MEMO/MRGATE) rejects the
message because it's too big.
The second error at 23:33 is probably caused by another message that is
larger than (or close to) the MRMEMO limit 500 KB. MRMEMO doesn't handle
this situation well - overflows its buffer and crashes. There is a patch
for this (note 5.13) that you could try.
Anders
PS
In case someone wonders how 470 blocks of message file can become 500 KB
of MEMO message, it's due to the not very space efficient MEMO protocol.
Every message line is padded with spaces to the defined message line
length (specified by MRMMan> DEFINE/TEXT_LINES=WIDTH=n). Also, any tab
characters in the MR message are converted to spaces.
|