Bug 42871 - Asynchronous Stream Read after Process Dispose Throws System.ObjectDisposedException
Summary: Asynchronous Stream Read after Process Dispose Throws System.ObjectDisposedEx...
Status: NEEDINFO
Alias: None
Product: Class Libraries
Classification: Mono
Component: System (show other bugs)
Version: 4.4.0 (C7)
Hardware: PC Linux
: --- normal
Target Milestone: Untriaged
Assignee: Bugzilla
URL:
Depends on:
Blocks:
 
Reported: 2016-07-28 10:34 UTC by Kratzer Kevin
Modified: 2016-08-09 14:36 UTC (History)
2 users (show)

See Also:
Tags:
Is this bug a regression?: ---
Last known good build:


Attachments

Description Kratzer Kevin 2016-07-28 10:34:22 UTC
We are using mono 4.4.1.0-0xamarin1 on ubuntu.
After the dispose of a System.Diagnostics.Process the VM often crashes with the following stack trace:

Unhandled Exception:
System.ObjectDisposedException: Cannot access a disposed object.
Object name: 'Stream has been closed'.
  at System.IO.FileStream.BeginRead (System.Byte[] array, Int32 offset, Int32 numBytes, System.AsyncCallback userCallback, System.Object stateObject) <0x7f5f73f0c1a0 + 0x00235> in <filename unknown>:0 
  at System.Diagnostics.AsyncStreamReader.ReadBuffer (IAsyncResult ar) <0x4135bee0 + 0x00425> in <filename unknown>:0 
  at System.IO.Stream+ReadWriteTask.InvokeAsyncCallback (System.Object completedTask) <0x7f5f73d6b920 + 0x0004f> in <filename unknown>:0 
  at System.Threading.ExecutionContext.RunInternal (System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, System.Object state, Boolean preserveSyncCtx) <0x7f5f73e5a990 + 0x00178> in <filename unknown>:0 
  at System.Threading.ExecutionContext.Run (System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, System.Object state, Boolean preserveSyncCtx) <0x7f5f73e5a960 + 0x00020> in <filename unknown>:0 
  at System.IO.Stream+ReadWriteTask.System.Threading.Tasks.ITaskCompletionAction.Invoke (System.Threading.Tasks.Task completingTask) <0x7f5f73d6b990 + 0x00103> in <filename unknown>:0 
  at System.Threading.Tasks.Task.FinishContinuations () <0x7f5f73e497e0 + 0x00214> in <filename unknown>:0 
  at System.Threading.Tasks.Task.FinishStageThree () <0x7f5f73e47bf0 + 0x00068> in <filename unknown>:0 
  at System.Threading.Tasks.Task.FinishStageTwo () <0x7f5f73e47a90 + 0x00133> in <filename unknown>:0 
  at System.Threading.Tasks.Task.Finish (Boolean bUserDelegateExecuted) <0x7f5f73e478f0 + 0x0008d> in <filename unknown>:0 
  at System.Threading.Tasks.Task.ExecuteWithThreadLocal (System.Threading.Tasks.Task& currentTaskSlot) <0x7f5f73e48620 + 0x00131> in <filename unknown>:0 
  at System.Threading.Tasks.Task.ExecuteEntry (Boolean bPreventDoubleExecution) <0x7f5f73e484c0 + 0x000ee> in <filename unknown>:0 
  at System.Threading.Tasks.Task.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem () <0x7f5f73e48440 + 0x0000e> in <filename unknown>:0 
  at System.Threading.ThreadPoolWorkQueue.Dispatch () <0x7f5f73e5f2e0 + 0x001d6> in <filename unknown>:0 
  at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback () <0x7f5f73e60bf0 + 0x00008> in <filename unknown>:0 

This behaviour could not be confirmed for Mono  "Stable 4.2.3.4/832de4b".

Maybe the process dispose, which only sets the streams to null, leaves the responsibility for the dispose of the streams to the GC which leads to a wrong dispose sequence of the streams. This might allow the AsyncStreamReader to read more data after the underlying stream has already been closed by the GC.

standardOutput = null;
standardInput = null;
standardError = null;

output = null; // AsyncStreamReader
error = null; // AsyncStreamReader
https://github.com/mono/mono/blob/d70777a3332af2d630d24adf620c2e548b92b56a/mcs/class/referencesource/System/services/monitoring/system/diagnosticts/Process.cs#L1335


Maybe this PR which was merged into the mono-4.3.2-branch is related to this behaviour:
https://github.com/mono/mono/pull/2515
Comment 1 Marek Safar 2016-08-09 14:36:55 UTC
Could you provide some steps how to reproduce the issue?

Note You need to log in before you can comment on or make changes to this bug.