Bug 34064 - Possible Thread.Join issue with Mono runtime
Summary: Possible Thread.Join issue with Mono runtime
Status: RESOLVED NORESPONSE
Alias: None
Product: Runtime
Classification: Mono
Component: JIT ()
Version: 4.0.0
Hardware: PC Linux
: --- normal
Target Milestone: ---
Assignee: Ludovic Henry
URL:
Depends on:
Blocks:
 
Reported: 2015-09-18 12:45 UTC by William Holroyd
Modified: 2017-04-10 17:55 UTC (History)
3 users (show)

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


Attachments
coredump main (903.66 KB, application/zip)
2015-09-18 12:54 UTC, William Holroyd
Details
coredump part 1 (7.81 MB, application/octet-stream)
2015-09-18 12:55 UTC, William Holroyd
Details
coredump part 2 (7.81 MB, application/octet-stream)
2015-09-18 12:56 UTC, William Holroyd
Details
coredump part 5 (7.81 MB, application/octet-stream)
2015-09-18 12:57 UTC, William Holroyd
Details
coredump part 3 (7.81 MB, application/octet-stream)
2015-09-18 12:58 UTC, William Holroyd
Details
coredump part 4 (7.81 MB, application/octet-stream)
2015-09-18 12:59 UTC, William Holroyd
Details
coredump part 6 (7.81 MB, application/octet-stream)
2015-09-18 12:59 UTC, William Holroyd
Details


Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.


Please create a new report on GitHub or Developer Community with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:
Status:
RESOLVED NORESPONSE

Description William Holroyd 2015-09-18 12:45:03 UTC
I have a simple single view/controller app that I use as a sample app in my proof of concept service fabric work. I have run into an issue with running Xunit tests on DNX beta7 over Mono 4.0.4.1/5ab4c0d using Fedora 22. The code that is available on GitHub at https://github.com/wholroyd/fake-dnx and reproduceable with commit 5c2ac31.

The test runner doesn't successfully return once it's done, it simply hangs indefinitely until manually killed and the console session doesn't respond to any input, even Ctrl-C.

I've already verified with Brad Wilson that this issue is not an issue with Xunit itself. I don't believe the issue to be with Xunit or DNX as it appears to work fine on Windows. It reads almost exactly like the issue in Mono bug 28793 (http://www.debugthings.com/2015/04/07/debugging-vnext-mono/), but the thread isn't waiting on itself, but on some other handle I can't traverse due to an unknown issue with GDB or the Mono support it has.

The issue I believe sits somewhere on the handle that thread 2 is waiting on. Notice the errors in both of the thread 2 backtraces below. Please let me know how I can help provide more information if this isn't enough.

########## Threads

(gdb) info threads
  Id   Target Id         Frame 
  3    Thread 0x7f36b7338700 (LWP 6844) "Finalizer" 0x00007f36be1e5829 in futex_abstimed_wait (cancel=true, 
    private=<optimized out>, abstime=0x0, expected=0, futex=0x958d80 <finalizer_sem>) at sem_waitcommon.c:42
  2    Thread 0x7f36adff8700 (LWP 6854) "mono" pthread_cond_wait@@GLIBC_2.3.2 ()
    at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
* 1    Thread 0x7f36bed00780 (LWP 6840) "mono" pthread_cond_wait@@GLIBC_2.3.2 ()
    at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185

########## Thread 2 backtrace

(gdb) bt
#0  pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x00000000006092b3 in _wapi_handle_timedwait_signal_handle ()
#2  0x000000000061c6db in wapi_WaitForSingleObjectEx ()
#3  0x000000000059033f in mono_wait_uninterrupted.constprop ()
#4  0x00000000005918f9 in ves_icall_System_Threading_WaitHandle_WaitOne_internal ()
#5  0x0000000040c5bf4d in ?? ()
#6  0x00007f36a8001450 in ?? ()
#7  0x00000000040b40a0 in ?? ()
#8  0x00007f36adb6b728 in ?? ()
#9  0x00007f36adb6b728 in ?? ()
#10 0x00007f36b6fd9e50 in ?? ()
#11 0x00007f3688000bd0 in ?? ()
#12 0x00007f3600000002 in ?? ()
#13 0x00007f36adff74d0 in ?? ()
#14 0x00007f36adff7450 in ?? ()
../../gdb/dwarf2-frame.c:683: internal-error: Unknown CFI encountered.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) n

This is a bug, please report it.  For instructions, see:
<http://www.gnu.org/software/gdb/bugs/>.

../../gdb/dwarf2-frame.c:683: internal-error: Unknown CFI encountered.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Create a core file of GDB? (y or n) n
Command aborted.

########## Thread 2 mono_backtrace

(gdb) mono_backtrace 10
#0  pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
185     62:     movl    (%rsp), %edi
#1  0x00000000006092b3 in _wapi_handle_timedwait_signal_handle ()
#2  0x000000000061c6db in wapi_WaitForSingleObjectEx ()
#3  0x000000000059033f in mono_wait_uninterrupted.constprop ()
#4  0x00000000005918f9 in ves_icall_System_Threading_WaitHandle_WaitOne_internal ()
#5 0x40c5bf4d in Cannot access memory at address 0xffffffff889fe930

########## Thread 2 mono_stack

"<unnamed thread>" tid=0x0x7f36adff8700 this=0x0x7f36af17ae40 thread handle 0x4c7 state : waiting on 0x4c5 : Event  owns ()
  at <unknown> <0xffffffff>
  at (wrapper managed-to-native) System.Threading.WaitHandle.WaitOne_internal (System.Threading.WaitHandle,intptr,int,bool) <0xffffffff>
  at System.Threading.WaitHandle.WaitOne () <0x0005c>
  at Xunit.Sdk.XunitWorkerThread.Join () <0x0001a>
  at Xunit.Sdk.MaxConcurrencySyncContext.Dispose () <0x0007f>
  at Xunit.Sdk.XunitTestAssemblyRunner.Dispose () <0x00025>
  at Xunit.Sdk.XunitTestFrameworkExecutor/<RunTestCases>d__6.MoveNext () <0x00298>
  at System.Runtime.CompilerServices.AsyncMethodBuilderCore/MoveNextRunner.InvokeMoveNext (object) <0x000be>
  at System.Threading.ExecutionContext.Run (System.Threading.ExecutionContext,System.Threading.ContextCallback,object) <0x0009b>
  at System.Threading.ExecutionContext.Run (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool) <0x00016>
  at System.Runtime.CompilerServices.AsyncMethodBuilderCore/MoveNextRunner.Run () <0x000ca>
  at System.Threading.Tasks.SynchronizationContextAwaitTaskContinuation.<s_postCallback>m__0 (object) <0x0003c>
  at Xunit.Sdk.MaxConcurrencySyncContext.RunOnSyncContext (System.Threading.SendOrPostCallback,object) <0x0005a>
  at Xunit.Sdk.MaxConcurrencySyncContext/<>c__DisplayClass11_0.<WorkerThreadProc>b__0 (object) <0x0002f>
  at System.Threading.ExecutionContext.Run (System.Threading.ExecutionContext,System.Threading.ContextCallback,object) <0x0009b>
  at (wrapper dynamic-method) object.lambda_method (System.Runtime.CompilerServices.Closure,object,object) <0x00061>
  at Xunit.Sdk.ExecutionContextHelper.Run (object,System.Action`1<object>) <0x00042>
  at Xunit.Sdk.MaxConcurrencySyncContext.WorkerThreadProc () <0x001a7>
  at Xunit.Sdk.XunitWorkerThread/<>c.<QueueUserWorkItem>b__5_0 (object) <0x00052>
  at System.Threading.Tasks.Task.InnerInvoke () <0x00085>
  at System.Threading.Tasks.Task.Execute () <0x00046>
  at System.Threading.Tasks.Task.ExecutionContextCallback (object) <0x0004e>
  at System.Threading.ExecutionContext.Run (System.Threading.ExecutionContext,System.Threading.ContextCallback,object) <0x0009b>
  at System.Threading.ExecutionContext.Run (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool) <0x00016>
  at System.Threading.Tasks.Task.ExecuteWithThreadLocal (System.Threading.Tasks.Task&) <0x00109>
  at System.Threading.Tasks.Task.ExecuteEntry (bool) <0x000f1>
  at System.Threading.Tasks.ThreadPoolTaskScheduler.LongRunningThreadWork (object) <0x00050>
  at System.Threading.Thread.StartInternal () <0x000f6>
  at (wrapper runtime-invoke) object.runtime_invoke_void__this__ (object,intptr,intptr,intptr) <0xffffffff>

########### Generate Core File

(gdb) generate-core-file 
warning: target file /proc/6840/cmdline contained unexpected null characters
warning: Memory read failed for corefile section, 8192 bytes at 0x7ffdf458f000.
Saved corefile core.6840
Comment 1 William Holroyd 2015-09-18 12:54:05 UTC
Created attachment 12949 [details]
coredump main
Comment 2 William Holroyd 2015-09-18 12:55:05 UTC
Created attachment 12950 [details]
coredump part 1
Comment 3 William Holroyd 2015-09-18 12:56:23 UTC
Created attachment 12951 [details]
coredump part 2
Comment 4 William Holroyd 2015-09-18 12:57:46 UTC
Created attachment 12953 [details]
coredump part 5
Comment 5 William Holroyd 2015-09-18 12:58:54 UTC
Created attachment 12954 [details]
coredump part 3
Comment 6 William Holroyd 2015-09-18 12:59:22 UTC
Created attachment 12955 [details]
coredump part 4
Comment 7 William Holroyd 2015-09-18 12:59:52 UTC
Created attachment 12956 [details]
coredump part 6
Comment 8 Ludovic Henry 2015-09-21 05:24:59 UTC
Hi William,

I tried to have a look at your coredump, but unfortunately I get an error trying to inflate the unsplitted zip file.

Maybe you can try sending me directly the coredump zip file unsplitted via email, as it seems it is around 16MB.

Thank you for the report!
Ludovic
Comment 9 William Holroyd 2015-09-21 10:12:07 UTC
That doesn't seem right, did you download all 7 files attached to this bug? The last 6 are 8MB each.
Comment 10 Ludovic Henry 2015-09-21 11:01:48 UTC
Yes, and I tried to put them back together, but I still get an error on OSX and Ubuntu 64bits
Comment 11 William Holroyd 2015-09-21 14:16:25 UTC
Interesting. I uploaded the full, single Zip file to ShareFile. It should be there the next few days.

https://electricsky.sharefile.com/d-se0205e6d8aa44c49
Comment 12 William Holroyd 2015-09-27 21:34:18 UTC
Did the full coredump file work better?
Comment 13 Ludovic Henry 2017-02-08 19:58:15 UTC
I could never reproduce, so if you still witness this bug, please provide us with a repro. Thank you.
Comment 14 Ludovic Henry 2017-04-10 17:55:47 UTC
If you can still reproduce, please reopen the bug with more information. Thank you.