wx3270 IND$FILE uploads crash with default buffer size
3270 Terminal Emulator
Brought to you by:
pmattes
Menu
▾
▴
#34 wx3270 IND$FILE uploads crash with default buffer size
Tested in 1.1ga4 and 1.1ga5.
When using IND$FILE file transfer to upload a file to TSO or CMS, wx3270 crashes with XML errors usually at the end of the transfer or shortly after. (For example a transfer at the TSO ready prompt might not crash until relaunching ISPF or when TSO clears the window after reaching the end of the screen and 3 asterisks. Quite often I get the failure immediately on an oversized terminal, but a model 2 might take a bit longer to crash)
I have not had any issues with downloads.
These are the most common errors I've seen:
Fatal Error: Caught exception while processing back-end message:
System.Xml.XmlException: Unexpected end of file has occurred. The following elements are not closed: row, screen, b3270-out. Line 1204, position 511.
at System.Xml.XmlTextReaderImpl.Throw(Exception e)
at System.Xml.XmlTextReaderImpl.ThrowUnclosedElements()
at System.Xml.XmlTextReaderImpl.<ParseAttributesAsync>d__533.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Xml.AsyncHelper.<_ReturnTaskBoolWhenFinish>d__8.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at Wx3270.BackEnd.<ReadEmulatorStream>d__56.MoveNext()
Fatal Error: Caught exception while processing back-end message:
System.Xml.XmlException: There is an unclosed literal string. Line 1757, position 956.
at System.Xml.XmlTextReaderImpl.Throw(Exception e)
at System.Xml.XmlTextReaderImpl.<ParseAttributeValueSlowAsync>d__534.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Xml.XmlTextReaderImpl.<ParseAttributesAsync>d__533.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Xml.AsyncHelper.<_ReturnTaskBoolWhenFinish>d__8.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at Wx3270.BackEnd.<ReadEmulatorStream>d__56.MoveNext()
wx3270 is picking up a culture of en-AU and effective culture of en. I tried using "-culture en-US" on the command line and initially I thought this helped, but it didn't.
After investigating further, I have found that the default value of ftBufferSize=16384 seems to be causing the problem. If I lower ftBufferSize just a little, say to 16000 or 8192, the crashes so far appear to have stopped.
While this can be set in the dialog, there isn't an option in the profile to override the 16384 default, so my workaround is to set it in the login macro for each session I have defined:
"LoginMacro": "set(ftBufferSize,16000)",
(I only just found this was a workaround today, so I haven't extensively tested it.)
I'm not sure how reproducible this error is for others, but I have seen it both under z/OS and z/VM.
This one is going to be a bit trickier to figure out. The XML error is an indication that the b3270 back-end process has exited unexpectedly. There is often more than one error pop-up in this case -- one for all the unclosed XML elements, and another for the child process exiting unexpectedly. Is there a second pop-up?
I have automated tests to verify IND$FILE operation and have not seen this, but I will see if there is a hole in my coverage. Also, I am a bit confused why the behavior is different with different screen sizes but is fixed by changing the ftBufferSize. On the surface, that's contradictory: There are two different modes for IND$FILE, CUT and DFT. CUT mode uses the screen buffer so it makes sense that its behavior would vary with the screen size. But CUT mode ignores ftBufferSize. DFT mode uses structured fields, and its behavior is completely independent of the screen size; however its buffering behavior is controlled by the ftBufferSize.
So -- two more questions. First, at the end of the file transfer, does the confirmation message refer to CUT mode or DFT mode? Second, would it be possible for you to capture a data stream trace of the file transfer and crash? That would help immensely.
Yes there is often (but not always) the two error dialogs with the other being back-end error "Back-end process exited with status -1073740940 (0xC0000374).
Here is one trace which is an existing session on an oversize mod-5. I exited ISPF to the TSO ready prompt, trace enabled, then a file transfer with ftBufferSize of 16384.
After the transfer, I attempted to relaunch ISPF (search for "ispf" in the trace file) at which point it crashed with the above back-end error as well as:
Trace file attached.
Forgot to mention the transfers are all DFT mode.
Second attempt using a mod-2 with different profile settings. Once again exited ISPF to TSO, then started transfer with ftBuffersize=16384. After transfer I relaunched ISPF at which point wx3270 crashed. (So at least it is consistent this time, but I am sure I've seen cases where it take a bit more activity before it crashes.)
This time I got:
and
Trace file attached.
I don't know if it is useful at all, but I also have a similar trace to the first one where I have used ftBuffersize=16000 and it didn't crash. To my untrained eye there the trace files aren't too different except that one stops and the other doesn't.
At the moment, I can't reproduce the different behaviour (delayed crash) with a mod-2, please ignore that aspect of the issue.
Status 0xC0000374 is heap corruption. So somewhere in the file transfer, b3270 is corrupting its heap. This does not happen during my unit tests, which do include a full-buffer-length DFT transfer to the host. But it is not a binary transfer, nor is it much longer than 16 Kbytes. I will keep digging, but in the meantime, could you attach a copy of the binary test file that you were using for the 37476 trace? I can add that very transfer to as a unit test, and see if it blows up here.
Here is the file I was uploading.
I've been doing some further testing with a plain non-TLS telnet session and can't reproduce the failure under those circumstances. So I believe the TLS session is important to reproducing the error.
That was the final clue. Found the cause.