Re: [Mono-dev] Shutdown hangs
I saw something similar when I was testing 4.2.2 awhile back, a rare hang on Exit with the main thread waiting like yours. I haven't tried 4.2.3 to see if our hang reproduces yet. We're still on 4.0.4 and we don't see it there. In the hang we saw, I also had one thread in pthread_cond_wait like yours, though we had two threads also in poll() with libusb_handle_events_timeout_completed () further up the stack. (gdb) info threads Id Target Id Frame 16 Thread 0x7f5eb0bff700 (LWP 2763) "mono" pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 15 Thread 0x7f5eae7e1700 (LWP 2765) "Finalizer" sem_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_wait.S:85 14 Thread 0x7f5ead26b700 (LWP 2784) "Timer-Scheduler" sem_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_wait.S:85 13 Thread 0x7f5eacf2f700 (LWP 2806) "Top" sem_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_wait.S:85 12 Thread 0x7f5eacd2a700 (LWP 2807) "Top" 0x7f5eb1b48b9d in nanosleep () at ../sysdeps/unix/syscall-template.S:81 11 Thread 0x7f5e8e07b700 (LWP 2840) "Top" sem_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_wait.S:85 * 10 Thread 0x7f5e72fa5700 (LWP 2980) "Top" 0x7f5eb186112d in poll () at ../sysdeps/unix/syscall-template.S:81 9Thread 0x7f5e727a4700 (LWP 2981) "Top" 0x7f5eb186112d in poll () at ../sysdeps/unix/syscall-template.S:81 8Thread 0x7f5e71a7b700 (LWP 3531) "Top" sem_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_wait.S:85 7Thread 0x7f5e7187a700 (LWP 3532) "Top" sem_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_wait.S:85 6Thread 0x7f5e706a3700 (LWP 3562) "Top" sem_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_wait.S:85 5Thread 0x7f5e704a2700 (LWP 3563) "Top" sem_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_wait.S:85 4Thread 0x7f5e579fc700 (LWP 3594) "Top" sem_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_wait.S:85 3Thread 0x7f5e577fb700 (LWP 3595) "Top" sem_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_wait.S:85 2Thread 0x7f5e565f2700 (LWP 3876) "Top" sem_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_wait.S:85 1Thread 0x7f5eb266f7c0 (LWP 2758) "Top" sem_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_wait.S:85 -Original Message- From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-boun...@lists.ximian.com] On Behalf Of Chris Swiedler Sent: Monday, June 13, 2016 9:55 AM To: mono-devel-list Subject: [Mono-dev] Shutdown hangs I'm getting semi-reliable shutdown hangs in a mono command-line app using mono 4.2.3 on Centos 7 64-bit. The app does different things at different times, and the shutdowns only seem to happen when it connects to our SQL server database (using the Mono database bindings, not ODBC). We've also seen an occasional segfault, also seemingly only when doing database work, though those may have gone away since upgrading to 4.2.3. Does anyone have any thoughts? Pstack output below. Thanks, chris Thread 5 (Thread 0x7f4c777ff700 (LWP 11658)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x005f786c in thread_func (thread_data=0x0) at sgen-thread-pool.c:118 #2 0x7f4c77ffedf5 in start_thread (arg=0x7f4c777ff700) at pthread_create.c:308 #3 0x7f4c77d2c1ad in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 Thread 4 (Thread 0x7f4c75560700 (LWP 11659)): #0 sem_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_wait.S:85 #1 0x0061aa37 in mono_sem_wait (sem=sem@entry=0x953c40 , alertable=alertable@entry=1) at mono-semaphore.c:107 #2 0x005a1736 in finalizer_thread (unused=) at gc.c:1096 #3 0x005841e9 in start_wrapper_internal (data=) at threads.c:725 #4 start_wrapper (data=) at threads.c:772 #5 0x00621026 in inner_start_thread (arg=0x7fffda0d42e0) at mono-threads-posix.c:97 #6 0x7f4c77ffedf5 in start_thread (arg=0x7f4c75560700) at pthread_create.c:308 #7 0x7f4c77d2c1ad in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 Thread 3 (Thread 0x7f4c74fd3700 (LWP 11660)): #0 sem_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_wait.S:85 #1 0x0061aa37 in mono_sem_wait (sem=sem@entry=0x7f4c68000940, alertable=alertable@entry=0) at mono-semaphore.c:107 #2 0x0061f5ba in mono_thread_info_wait_for_resume (info=) at mono-threads.c:110 #3 mono_thread_info_end_self_suspend () at mono-threads.c:692 #4 0x00583d2c in self_suspend_internal (thread=0x7f4c78a74330) at threads.c:4546 #5 mono_thread_execute_interruption (thread=thread@entry=0x7f4c78a74330) at threads.c:4050 #6 0x00583f50 in mono_thread_interruption_checkpoint_request (bypass_abort_protection=bypass_abort_protection@entry=1) at threads.c:4184 #7 0x00584dae in
Re: [Mono-dev] gdb and mono
Awesome, thank you! Looks like that is in mono 4.3.2.467 and 4.4.x, I’ll give it a try. From: Zoltan Varga [mailto:var...@gmail.com] Sent: Monday, March 28, 2016 12:39 PM To: David Evans Cc: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] gdb and mono Hi, This was fixed some time ago by mono commit a6380f15f0db533e30870925e0125a859ab815cf. Zoltan On Mon, Mar 28, 2016 at 2:21 PM, David Evans <dev...@pacificbiosciences.com<mailto:dev...@pacificbiosciences.com>> wrote: Sorry if this has been covered before, or is a current issue, but is there a way around these errors using gdb with mono 4.x? I generally see “/build/buildd/gdb-7.7.1/gdb/dwarf2-frame.c:692: internal-error: Unknown CFI encountered.” whenever trying to look at things in gdb. Thx! (gdb) bt #0 sem_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_wait.S:85 #1 0x0061f977 in mono_sem_wait (sem=sem@entry=0x7fbacc000940, alertable=alertable@entry=0) at mono-semaphore.c:107 #2 0x0062465a in mono_thread_info_wait_for_resume (info=) at mono-threads.c:110 #3 mono_thread_info_end_self_suspend () at mono-threads.c:692 #4 0x005876dc in self_suspend_internal (thread=0x7fbadbb40430) at threads.c:4546 #5 mono_thread_execute_interruption (thread=thread@entry=0x7fbadbb40430) at threads.c:4050 #6 0x005879ac in mono_wait_uninterrupted (thread=thread@entry=0x7fbadbb40430, multiple=multiple@entry=0, numhandles=numhandles@entry=1, handles=handles@entry=0x7fbad67fd638, waitall=waitall@entry=0, ms=ms@entry=1725, alertable=1) at threads.c:1455 #7 0x00588f59 in ves_icall_System_Threading_WaitHandle_WaitOne_internal (this=, handle=0x100c, ms=1725, exitContext=) at threads.c:1583 #8 0x40962760 in ?? () #9 0x0038 in ?? () #10 0x02521f28 in ?? () #11 0x06bd in ?? () #12 0x7fbada29f278 in ?? () #13 0x06bd in ?? () #14 0x7fbacc000e01 in ?? () #15 0x41641e7d in ?? () #16 0x7fbad67fd6f0 in ?? () #17 0x7fbad67fd660 in ?? () /build/buildd/gdb-7.7.1/gdb/dwarf2-frame.c:692: 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 /build/buildd/gdb-7.7.1/gdb/dwarf2-frame.c:692: 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. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com<mailto:Mono-devel-list@lists.ximian.com> http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] gdb and mono
Sorry if this has been covered before, or is a current issue, but is there a way around these errors using gdb with mono 4.x? I generally see "/build/buildd/gdb-7.7.1/gdb/dwarf2-frame.c:692: internal-error: Unknown CFI encountered." whenever trying to look at things in gdb. Thx! (gdb) bt #0 sem_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_wait.S:85 #1 0x0061f977 in mono_sem_wait (sem=sem@entry=0x7fbacc000940, alertable=alertable@entry=0) at mono-semaphore.c:107 #2 0x0062465a in mono_thread_info_wait_for_resume (info=) at mono-threads.c:110 #3 mono_thread_info_end_self_suspend () at mono-threads.c:692 #4 0x005876dc in self_suspend_internal (thread=0x7fbadbb40430) at threads.c:4546 #5 mono_thread_execute_interruption (thread=thread@entry=0x7fbadbb40430) at threads.c:4050 #6 0x005879ac in mono_wait_uninterrupted (thread=thread@entry=0x7fbadbb40430, multiple=multiple@entry=0, numhandles=numhandles@entry=1, handles=handles@entry=0x7fbad67fd638, waitall=waitall@entry=0, ms=ms@entry=1725, alertable=1) at threads.c:1455 #7 0x00588f59 in ves_icall_System_Threading_WaitHandle_WaitOne_internal (this=, handle=0x100c, ms=1725, exitContext=) at threads.c:1583 #8 0x40962760 in ?? () #9 0x0038 in ?? () #10 0x02521f28 in ?? () #11 0x06bd in ?? () #12 0x7fbada29f278 in ?? () #13 0x06bd in ?? () #14 0x7fbacc000e01 in ?? () #15 0x41641e7d in ?? () #16 0x7fbad67fd6f0 in ?? () #17 0x7fbad67fd660 in ?? () /build/buildd/gdb-7.7.1/gdb/dwarf2-frame.c:692: 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 /build/buildd/gdb-7.7.1/gdb/dwarf2-frame.c:692: 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. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Socket with ProtocolType.Udp hangs occasionally in ReceiveFrom()
Hi All, I'm seeing a rare hang in Socket.ReceiveFrom() where the receive timeout isn't respected. What's also odd is then on the server side once this wedge occurs the server gets the same packet that had been sent to it over and over and it keeps responding to it endlessly - but the client never returns from ReceiveFrom(). This is in a test sending packets over localhost between two threads. Then, if I switch to use Socket.Connect(), Socket.Send(), and Socket.Receive() instead the problem doesn't occur. Appears to only get me if I use the SendTo/ReceiveFrom variants, which I gather are more commonly used for UDP sockets. I filed a bug with a test app to reproduce it, but wanted to mention it in case anyone else has run into this already or can point out if I'm doing something incorrectly: https://bugzilla.xamarin.com/show_bug.cgi?id=39332 Reproduced this with mono 4.0.4.1, 4.2.2.30, and 4.3.2.467 on Ubuntu 14.04.1 Best, David ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] xbuild leaking?
Hi all, We're using xbuild for a fairly large project now on linux with 4.0.4.1. We're noticing that the peak memory usage for the build seems to scale surprisingly fast with the total number of project references across the solution, as opposed to other measures. This isn't a big deal for us until we run out of physical memory and start swapping during the compile. My guess: xbuild is hanging onto symbol tables for all project references - even those for projects has finished building - until the whole build is complete. We haven't noticed the same behavior building with Xamarin. Does this ring a bell for anyone? I'd love to test out my theory and dig into that code (in particular how reference symbol tables are cached) but I wanted to check with folks here to see if this behavior might be intentional for some reason or if there is any known history about it. Thx! ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
