ess kill itself with SIGKILL, but I'd
rather not since then I lose the actual exit code.
chris
-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
mono-threads.c:652
#5 0x00589705 in suspend_thread_internal (thread=0x7f7d37312940,
interrupt=1) at threads.c:4707
#6 0x00589bdd in mono_thread_suspend_all_other_threads () at
threads.c:3142
#7 0x0053c0f6 in ves_icall_System_Environment_Exit (result=0) at
icall.c:6471
-Ori
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 se
threadpool-ms.c:509
From: Rodrigo Kumpera [mailto:kump...@gmail.com]
Sent: Friday, May 27, 2016 5:07 PM
To: Chris Swiedler
Cc: Ludovic Henry ; mono-devel-list
Subject: Re: [Mono-dev] High threadpool CPU usage
Chris,
Can you at least enable GC logging? That will tell you how frequently and for
: Chris Swiedler ; mono-devel-list
Subject: Re: [Mono-dev] High threadpool CPU usage
Hi Chris,
The signal handler you are seeing is the GC signalling every thread to suspend
them. So yes you are right, that's the sgen collector stopping the world.
To track down the large number of allocati
[mailto:ludo...@xamarin.com]
Sent: Thursday, May 26, 2016 8:43 AM
To: Chris Swiedler ; mono-devel-list
Subject: Re: [Mono-dev] High threadpool CPU usage
Hi Chris,
The first stacktrace you are observing is for threadpool thread parking. We use
this technique for threads that are currently not doing
We have a server app which is periodically going into a mode where all
threadpool threads start running at very high CPU. I've run pstack when it's in
this mode, and every time I do it, nearly all the threadpool threads have this
stack:
#0 pthread_cond_timedwait@@GLIBC_2.3.2 () at
../nptl/sys
:46 AM
To: Chris Swiedler ; mono-devel-list
Subject: Re: [Mono-dev] Reading threadpool performance counters
Hi Chris,
I don't think we are keeping this counters up to date in the threadpool. Some
of them are kept up to date, but as we imported the threadpool implementation
from referenceso
Per https://bugzilla.xamarin.com/show_bug.cgi?id=1772 I've been trying to get
Mono threadpool metrics with lines like this:
m_workItemsAdded = new PerformanceCounter("Mono Threadpool", "Work Items
Added", Process.GetCurrentProcess().Id.ToString());
However, the counter I get back always has
To Alan's point, we did see crashes when we (unintentionally) deployed
Mono.Posix.dll along with our app. Our solution was, like he said, to Not Do
That, and use our Mono.Posix as a compile-time library only.
I do think it's much easier to do it this way than to have different compile
targets,
Why not just include references to Mono.Posix.dll in the Windows build? You
don't have to install the full framework. We have a similar issue with server
apps that are developed on Windows and run on Linux. We just put a win32 build
of Mono into our source tree and added Mono.Posix as a referenc
vey (mono)
> wrote:
>
>> From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-
>> boun...@lists.ximian.com] On Behalf Of Chris Swiedler
>>
>> We have a server application that's being developed under Visual Studio and
>> run under Mon
We have a server application that's being developed under Visual Studio and run
under Mono 3.12. We're generating .mdb files from the .pdbs that VS creates.
With those deployed next to the executable, mono will give full callstacks with
source and line information when logging exceptions, so I b
13 matches
Mail list logo