[Mono-dev] Process freezes on Windows
Yosi Levy
yosilevy at gmail.com
Fri Oct 7 05:53:12 EDT 2011
Just to let everyone who'll encounter this know - the problem is when you
bundle assemblies in to the EXE. Apparently the load from bundle code has
some issues. This is stable if you just "bundle" the main EXE and leave all
other assemblies, including MONO out of it.
We don't have time right now to figure out the exact problem...
Thanks,
Jo Levy.
-----Original Message-----
From: mono-devel-list-bounces at lists.ximian.com
[mailto:mono-devel-list-bounces at lists.ximian.com] On Behalf Of
mono-devel-list-request at lists.ximian.com
Sent: Friday, October 07, 2011 11:20 AM
To: mono-devel-list at lists.ximian.com
Subject: Mono-devel-list Digest, Vol 78, Issue 4
Send Mono-devel-list mailing list submissions to
mono-devel-list at lists.ximian.com
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.ximian.com/mailman/listinfo/mono-devel-list
or, via email, send a message with subject or body 'help' to
mono-devel-list-request at lists.ximian.com
You can reach the person managing the list at
mono-devel-list-owner at lists.ximian.com
When replying, please edit your Subject line so it is more specific than
"Re: Contents of Mono-devel-list digest..."
Today's Topics:
1. Re: Process freezes on Windows (Yosi Levy)
2. Re: Socket.Accept() causes [1]+ Stopped (ykm)
3. Error using xsd (Stefano Canepa)
4. Re: Socket.Accept() causes [1]+ Stopped (DJL)
5. NuGet (Rolf Bjarne Kvinge)
----------------------------------------------------------------------
Message: 1
Date: Thu, 6 Oct 2011 00:31:56 +0200
From: "Yosi Levy" <yosilevy at gmail.com>
Subject: Re: [Mono-dev] Process freezes on Windows
To: <mono-devel-list at lists.ximian.com>
Message-ID: <00af01cc83ae$98d02df0$ca7089d0$@gmail.com>
Content-Type: text/plain; charset="us-ascii"
About the freeze - we have figured out the problem but not the solution.
The problem is a deadlock within mono_loader_lock. It seems multiple threads
are trying to lock the semaphore and we're not sure who actually got it and
is not releasing it.
We're debugging it now.
Anyone knows anything about this?
Is it just a problem in EXEs after MKBUNDLE?
Thanks,
Jo.
-----Original Message-----
From: mono-devel-list-bounces at lists.ximian.com
[mailto:mono-devel-list-bounces at lists.ximian.com] On Behalf Of
mono-devel-list-request at lists.ximian.com
Sent: Wednesday, October 05, 2011 8:37 PM
To: mono-devel-list at lists.ximian.com
Subject: Mono-devel-list Digest, Vol 78, Issue 3
Send Mono-devel-list mailing list submissions to
mono-devel-list at lists.ximian.com
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.ximian.com/mailman/listinfo/mono-devel-list
or, via email, send a message with subject or body 'help' to
mono-devel-list-request at lists.ximian.com
You can reach the person managing the list at
mono-devel-list-owner at lists.ximian.com
When replying, please edit your Subject line so it is more specific than
"Re: Contents of Mono-devel-list digest..."
Today's Topics:
1. Re: Mono Hard Debugger (MDB) for ARM (Martin D?umler)
2. Re: Mono Hard Debugger (MDB) for ARM (Alex)
3. Process freezes on Windows (Yosi Levy)
----------------------------------------------------------------------
Message: 1
Date: Wed, 05 Oct 2011 10:04:19 +0200
From: Martin D?umler <mdae at cs.tu-chemnitz.de>
Subject: Re: [Mono-dev] Mono Hard Debugger (MDB) for ARM
To: mono-devel-list at lists.ximian.com
Message-ID: <4E8C0F83.3000304 at cs.tu-chemnitz.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 05.10.2011 05:28, Rodrigo Kumpera wrote:
> The hard debugger is no longer supported. It has only made to work on
> linux x86/amd64.
>
Hello,
does the Soft-Debugger in Mono-2.8 or Mono-2.10 support breakpoints and
single stepping on ARM and x86?
With kind regards,
Martin D?umler
------------------------------
Message: 2
Date: Wed, 5 Oct 2011 14:20:52 +0200
From: Alex <xtzgzorex at gmail.com>
Subject: Re: [Mono-dev] Mono Hard Debugger (MDB) for ARM
To: Martin D?umler <mdae at cs.tu-chemnitz.de>
Cc: mono-devel-list at lists.ximian.com
Message-ID:
<CAEnAdhb+xnuVUX8xT5-Y4NdEKQSv72A9A-wHYOwQa4=U19n-bg at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Hi,
Yes, 2.10's soft debugger works on both x86(-64) and ARM.
Regards,
Alex
On Wed, Oct 5, 2011 at 10:04 AM, Martin D?umler <mdae at cs.tu-chemnitz.de>
wrote:
> On 05.10.2011 05:28, Rodrigo Kumpera wrote:
>> The hard debugger is no longer supported. It has only made to work on
>> linux x86/amd64.
>>
>
> Hello,
>
> does the Soft-Debugger in Mono-2.8 or Mono-2.10 support breakpoints
> and single stepping on ARM and x86?
>
>
> With kind regards,
> Martin D?umler
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
------------------------------
Message: 3
Date: Wed, 5 Oct 2011 20:36:30 +0200
From: "Yosi Levy" <yosilevy at gmail.com>
Subject: [Mono-dev] Process freezes on Windows
To: <mono-devel-list at lists.ximian.com>
Message-ID: <009301cc838d$b5103f30$1f30bd90$@gmail.com>
Content-Type: text/plain; charset="us-ascii"
Hi all,
We have a weird problem where it seems that threading use and locking is
caused our process to freeze. The weird thing is that it freezes sometimes
after 10 consecutive runs, sometimes after 200.
We're running an EXE bundled with MKBUNDLE on windows. It otherwise works
great.
We've compiled MONO-2.0.dll with debug info to know more.
The info is below. As you'll see there's an int 3 which was probably done by
debugger. Exception analysis just says BREAKPOINT so should we understand
that the process is just dead-locked?
How can we debug this (again - this is a bundled EXE) ?
It seems to be related to threading and locking since if we reduce usage of
C# lock statements, it freezes less.
Please help! Many thanks.
The info:
Thread that raised breakpoint:
Unflagged > 8172 0 Worker Thread
_threadstartex _callthreadstartex Normal 0000000000001111
0
It's disassembly:
__RtlUserThreadStart at 8:
77399E8A mov edi,edi
77399E8C push ebp
77399E8D mov ebp,esp
77399E8F push ecx
77399E90 push ecx
77399E91 lea eax,[ebp-8]
77399E94 push eax
77399E95 call _RtlInitializeExceptionChain at 4 (77399E6Fh)
77399E9A push dword ptr [ebp+0Ch]
77399E9D push dword ptr [ebp+8]
77399EA0 call ___RtlUserThreadStart at 8 (77399EABh)
77399EA5 int 3
77399EA6 nop
77399EA7 nop
77399EA8 nop
77399EA9 nop
77399EAA nop
Its Call-stack:
ntdll.dll!_ZwWaitForSingleObject at 12() + 0x15 bytes
ntdll.dll!_ZwWaitForSingleObject at 12() + 0x15 bytes
kernel32.dll!_WaitForSingleObjectExImplementation at 12() +
0x43 bytes
kernel32.dll!_WaitForSingleObject at 8() + 0x12 bytes
libdispatch.dll!0bec3ecb()
[Frames below may be incorrect and/or missing, no symbols
loaded for libdispatch.dll]
libdispatch.dll!0bec38c3()
libdispatch.dll!0bec3238()
libdispatch.dll!0bec2e6c()
libdispatch.dll!0bec3430()
libdispatch.dll!0bec325f()
pthreadVC2.dll!73714212()
msvcr80.dll!_callthreadstartex() Line 348 + 0x6 bytes C
msvcr80.dll!_threadstartex(void * ptd=0x028a9678) Line 326 +
0x5 bytes C
kernel32.dll!@BaseThreadInitThunk at 12() + 0x12 bytes
ntdll.dll!___RtlUserThreadStart at 8() + 0x27 bytes
> ntdll.dll!__RtlUserThreadStart at 8() + 0x1b bytes
All threads:
Unflagged 888 0 Worker Thread
__endthreadex _NtWaitForMultipleObjects at 20
Highest 0000000000001111 0
Unflagged 1208 0 Worker Thread
thread_start mono_jit_runtime_invoke Normal
0000000000001111 0
Unflagged 1384 0 Worker Thread
_TppWorkerThread at 4 _ZwWaitForWorkViaWorkerFactory at 8 Normal
0000000000001111 0
Unflagged 1440 0 Worker Thread
_TppWorkerThread at 4 _ZwWaitForWorkViaWorkerFactory at 8 Normal
0000000000001111 0
Unflagged 2840 0 Worker Thread
thread_start
ves_icall_System_Threading_WaitHandle_WaitOne_internal Normal
0000000000001111 0
Unflagged 3176 0 Worker Thread
__endthreadex _ZwWaitForSingleObject at 12 Time Critical
0000000000001111 0
Unflagged 3492 0 Worker Thread
_TppWorkerThread at 4 _ZwWaitForWorkViaWorkerFactory at 8 Normal
0000000000001111 0
Unflagged 3648 0 Worker Thread
CDeviceEnumerator::PnpNotificationThreadWrapper
_NtWaitForMultipleObjects at 20 Normal 0000000000001111
0
Unflagged 3772 0 Worker Thread
thread_start mono_sem_timedwait Normal 0000000000001111
0
Unflagged 4188 0 Worker Thread
Win32 Thread _ZwWaitForSingleObject at 12 Normal
0000000000001111 0
Unflagged 4948 0 Worker Thread
thread_start mono_jit_runtime_invoke Normal
0000000000001111 0
Unflagged 5708 0 Worker Thread
thread_start
ves_icall_System_Threading_WaitHandle_WaitOne_internal Normal
0000000000001111 0
Unflagged 5936 0 Worker Thread
Win32 Thread _ZwWaitForSingleObject at 12 Normal
0000000000001111 0
Unflagged 6092 0 Worker Thread
_TppWaiterpThread at 4 _NtWaitForMultipleObjects at 20
Normal 0000000000001111 0
Unflagged 6132 0 Worker Thread
thread_start monitor_thread Normal 0000000000001111
0
Unflagged 6276 0 Main Thread
Main Thread mono_get_lmf_addr Normal 0000000000001111
0
Unflagged 6364 0 Worker Thread
_threadstartex _callthreadstartex Normal 0000000000001111
0
Unflagged 6980 0 Worker Thread
_TppWorkerThread at 4 _ZwWaitForWorkViaWorkerFactory at 8 Normal
0000000000001111 0
Unflagged 7012 0 Worker Thread
__endthread _ZwWaitForSingleObject at 12 Time Critical
0000000000001111 0
Unflagged 7032 0 Worker Thread
thread_start
ves_icall_System_Threading_WaitHandle_WaitOne_internal Normal
0000000000001111 0
Unflagged 7220 0 Worker Thread
thread_start
ves_icall_System_Threading_WaitHandle_WaitOne_internal Normal
0000000000001111 0
Unflagged 7384 0 Worker Thread
CThread::ThreadStartRoutine _NtWaitForMultipleObjects at 20
Time Critical 0000000000001111 0
Unflagged 7520 0 Worker Thread
_TppWorkerThread at 4 _ZwWaitForWorkViaWorkerFactory at 8 Normal
0000000000001111 0
Unflagged 7564 0 Worker Thread
CThread::ThreadStartRoutine _NtWaitForMultipleObjects at 20
Time Critical 0000000000001111 0
Unflagged 7644 0 Worker Thread
thread_start mono_sem_timedwait Normal 0000000000001111
0
Unflagged 7744 0 Worker Thread
_TppWorkerThread at 4 _ZwWaitForWorkViaWorkerFactory at 8 Normal
0000000000001111 0
Unflagged 7896 0 Worker Thread
thread_start
ves_icall_System_Threading_WaitHandle_WaitOne_internal Normal
0000000000001111 0
Unflagged 7904 0 Worker Thread
thread_start
ves_icall_System_Threading_WaitHandle_WaitOne_internal Normal
0000000000001111 0
Unflagged 8040 0 Worker Thread
CThread::ThreadStartRoutine _NtWaitForMultipleObjects at 20
Time Critical 0000000000001111 0
Unflagged 8112 0 Worker Thread
DllRefCountSafeThreadThunk _NtWaitForMultipleObjects at 20
Normal 0000000000001111 0
Unflagged > 8172 0 Worker Thread
_threadstartex _callthreadstartex Normal 0000000000001111
0
Any ideas? I can provide a dump if anyone wants to help. We are releasing
tomorrow L. No choice here.
How can we know reason for this int 3
Thanks,
Jo.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.ximian.com/pipermail/mono-devel-list/attachments/20111005/2e6ff
5a8/attachment.html
------------------------------
_______________________________________________
Mono-devel-list mailing list
Mono-devel-list at lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
End of Mono-devel-list Digest, Vol 78, Issue 3
**********************************************
------------------------------
Message: 2
Date: Thu, 6 Oct 2011 02:30:49 -0700 (PDT)
From: ykm <ykmmumbai at gmail.com>
Subject: Re: [Mono-dev] Socket.Accept() causes [1]+ Stopped
To: mono-devel-list at lists.ximian.com
Message-ID: <1317893449174-3877545.post at n4.nabble.com>
Content-Type: text/plain; charset=us-ascii
well, i'm afraid I haven't so I could not comment on its usability. But the
whole idea behind asynchonous sockets was to shift the socket programming to
a seperate thread rather than the main thread. And we can achieve it
programmatically.
--
View this message in context:
http://mono.1490590.n4.nabble.com/Socket-Accept-causes-1-Stopped-tp3847351p3
877545.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
------------------------------
Message: 3
Date: Thu, 06 Oct 2011 11:33:50 +0200
From: Stefano Canepa <sc at linux.it>
Subject: [Mono-dev] Error using xsd
To: mono-devel-list at lists.ximian.com
Message-ID: <4E8D75FE.2050805 at linux.it>
Content-Type: text/plain; charset=ISO-8859-15
Dear all,
I'm trying to generate a .cs based on an xsd but I get following
error:
[s.canepa at proj13 VectorGraphicAnimation]$ xsd Vga.xsd /classes
/namespace:VectorGraphicAnimation /language:CS
System.InvalidCastException: Cannot cast from source type to destination
type.
at
System.Xml.Serialization.XmlSchemaImporter.CollectAttributeUsesNonOverlap
(System.Xml.Schema.XmlSchemaObjectCollection
src, System.Xml.Serialization.ClassMap map) [0x00000] in <filename
unknown>:0
at System.Xml.Serialization.XmlSchemaImporter.ImportAttributes
(System.Xml.XmlQualifiedName typeQName,
System.Xml.Serialization.ClassMap cmap,
System.Xml.Schema.XmlSchemaObjectCollection atts,
System.Xml.Schema.XmlSchemaAnyAttribute anyat,
System.Xml.Serialization.CodeIdentifiers classIds) [0x00000] in <filename
unknown>:0
at System.Xml.Serialization.XmlSchemaImporter.BuildClassMap
(System.Xml.Serialization.XmlTypeMapping map, System.Xml.XmlQualifiedName
typeQName, System.Xml.Schema.XmlSchemaComplexType stype) [0x00000] in
<filename
unknown>:0
at System.Xml.Serialization.XmlSchemaImporter.BuildPendingMaps ()
[0x00000] in <filename unknown>:0
at System.Xml.Serialization.XmlSchemaImporter.ImportTypeCommon
(System.Xml.XmlQualifiedName name, System.Xml.XmlQualifiedName qname,
System.Xml.Schema.XmlSchemaType stype, Boolean isNullable) [0x00000] in
<filename unknown>:0
at System.Xml.Serialization.XmlSchemaImporter.ImportTypeMapping
(System.Xml.XmlQualifiedName name) [0x00000] in <filename unknown>:0
at Mono.Util.Driver.GenerateClasses () [0x00000] in <filename unknown>:0
at Mono.Util.Driver.Run (System.String[] args) [0x00000] in <filename
unknown>:0
at Mono.Util.Driver.Main (System.String[] args) [0x00000] in <filename
unknown>:0
[s.canepa at proj13 VectorGraphicAnimation]$
What's going wrong?
If you need I can provide the XSD. Microsoft xsd utility generates a correct
cs I can use with mono but I would like to develop on Linux with mono.
Bye
Stefano
--
Stefano Canepa aka sc: sc at linux.it - http://www.stefanocanepa.it Three great
virtues of a programmer: laziness, impatience and hubris.
Le tre grandi virt? di un programmatore: pigrizia, impazienza e arroganza.
(Larry Wall)
------------------------------
Message: 4
Date: Thu, 6 Oct 2011 02:49:39 -0700 (PDT)
From: DJL <djleehaha at googlemail.com>
Subject: Re: [Mono-dev] Socket.Accept() causes [1]+ Stopped
To: mono-devel-list at lists.ximian.com
Message-ID: <1317894579059-3877587.post at n4.nabble.com>
Content-Type: text/plain; charset=us-ascii
Thanks for your help guys
Unfortunatly I've not had much time to investigate further on this issue
however I am 90% sure that Async of the Accept method will NOT solve this
problem.
The program is not just freezing and waiting for something, it is actually
completely stopping and won't continue until typing /fg/ at the
commandline.
The 2 symptoms are, at least in my experience so far, quite different.
The bash script is supposed to connect to this socket as part of its
processing, and since that is running in its own process the Accept() method
should not block for more than a few milliseconds (even if it was a whole
second, that would be quite acceptable)
Furthermore, there is no other processing I can perform until the Accept()
call returns anyway - so farming it off to a background thread would be
pointless...
I suspect, as Robert suggested last week, that something in the bash script
is somehow causing my application to stop.
I did do some fiddling and I think ffmpeg (part of the bash script) is
somehow doing this.
The bash script goes something along these lines:
/cd /some/path ; ( ffmpeg -i somefile.mpg | netcat 127.0.0.1 1234 ) 2>&1/
Although I suspect this is now the wrong place to be asking for help since
it appears it could be a bash/ffmpeg issue
N.B. The above may seem like an odd thing to be doing - i.e. redirecting
stdout via tcpip instead of just using Process.StandardOut
the reason is I was having issues with using Process.StandardOut and
Process.StandardError at the same time (reading from different threads
before you mention that) - for some reason ffmpeg would appear to just hang
when doing this and no output on either stdout or stderr.
I'm now wondering if these 2 symptoms are related?
if I change the bash script to be
/cd /some/path ; ( cat /dev/null | ffmpeg -i somefile.mpg | netcat 127.0.0.1
1234 ) 2>&1/
It works - however this is no use to me since sometimes the input to ffmpeg
will be stdin - and the code doesn't proceed far enough for me to write
anything to stdin ...
anyone have any thoughts? or should I post this on a bash forum?
-----
DJL's Deep Decks live every Wednesday night from 8PM* on
www.housefreaks.co.uk Channel1 - Deep/Tech & Minimal House
http://www.dj-djl.com
*UK Time
--
View this message in context:
http://mono.1490590.n4.nabble.com/Socket-Accept-causes-1-Stopped-tp3847351p3
877587.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
------------------------------
Message: 5
Date: Fri, 7 Oct 2011 11:20:05 +0200
From: Rolf Bjarne Kvinge <rolf at xamarin.com>
Subject: [Mono-dev] NuGet
To: mono-devel-list at lists.ximian.com
Message-ID:
<CAP-t258xCCrvwE6sHYpN_-BywphwiZ61vNSjd=FLKLcDKPnCDA at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi,
I've tried to make the NuGet commandline client working with mono, and today
I committed the latest fixes which makes the basic operations (spec, pack,
publish/push) work using mono master.
To build NuGet using mono master [1] a couple of minor changes are required
(see attached diff):
* Core: A few "X is not CLS compliant" warnings are shown in mono which
fails the build since NuGet has warnings as errors turned on (so I just
turned those into warnings again).
* CommandLine: NuGet tries to merge the core library into the command line
executable using ILMerge, which obviously isn't available on anywhere but
Windows (I skipped the merging completely, this means you'll have a
NuGet.Core.dll and a NuGet.exe instead of just a NuGet.exe).
So to build NuGet, all you have to do is to get the source, apply the
provided patch, and:
cd nuget/src/Core && xbuild
cd ../CommandLine && xbuild
cd bin/Debug
$ mono NuGet.exe help
NuGet Version: 1.6.0.0
<help message>
I hope this helps if somebody wants to use NuGet :)
For the future we're planning to write a NuGet addin to MonoDevelop (it will
take some time though).
Rolf
[1]: With the fix here: http://bugzilla.xamarin.com/show_bug.cgi?id=983 it
will also build using 2.10.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.ximian.com/pipermail/mono-devel-list/attachments/20111007/5b6c0
8ec/attachment.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mono.patch
Type: application/octet-stream
Size: 1955 bytes
Desc: not available
Url :
http://lists.ximian.com/pipermail/mono-devel-list/attachments/20111007/5b6c0
8ec/attachment.obj
------------------------------
_______________________________________________
Mono-devel-list mailing list
Mono-devel-list at lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
End of Mono-devel-list Digest, Vol 78, Issue 4
**********************************************
More information about the Mono-devel-list
mailing list