date:20101214

[Mono-dev] Mono Service crashs

2010-12-14 Thread Chakotey STME

Hello Community,

I have a problem with a mono-service.
I have a mono-service in which I host a WCF-Service.
I start the software with mono-service2 and it works fine.
After a while (I can't say when exactly - sometimes after 1 hour,
sometimes after 4 hours) the service crashs.
There is no more mono-service-process on the linux-system.
The lock-file in the /tmp-Directory still exists.
So it have to be a crash as the reason the service isn't there
anymore, haven't it?

So what can I do to identify the problem?
Is it a unhandled exception? How can I find it out? Because in the
ServiceHost of the service I catch all Exception (or I believe it).
Is there something like a log-file to identify this problem?
The service worked in the background, so I had no messages at the console.

I hope you can help me with this problem.

Thanks,

chakoteystme
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Mono Service crashs

2010-12-14 Thread Robert Jordan

On 14.12.2010 16:16, Chakotey STME wrote:
> Hello Community,
>
> I have a problem with a mono-service.
> I have a mono-service in which I host a WCF-Service.
> I start the software with mono-service2 and it works fine.
> After a while (I can't say when exactly - sometimes after 1 hour,
> sometimes after 4 hours) the service crashs.
> There is no more mono-service-process on the linux-system.
> The lock-file in the /tmp-Directory still exists.
> So it have to be a crash as the reason the service isn't there
> anymore, haven't it?
>
> So what can I do to identify the problem?
> Is it a unhandled exception? How can I find it out? Because in the
> ServiceHost of the service I catch all Exception (or I believe it).
> Is there something like a log-file to identify this problem?
> The service worked in the background, so I had no messages at the console.

Use the "--debug" switch to redirect stdout+err to
a log file of your choice and put the whole thing
into background with the trailing "&"

nohup mono-service2 --debug   > /tmp/mylogfile 2>&1 &

Robert

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

[Mono-dev] Mono/.NET Framework Very Different Stack Traces

2010-12-14 Thread Bryan Murphy

I have a very simple test program:

01 using System;
02
03 public static class Program {
04public static void ThrowCatchRethrow() {
05try {
06throw new InvalidOperationException();
07} catch (Exception) {
08throw;
09}
10}
11
12public static void Main(string[] args) {
13try {
14ThrowCatchRethrow();
15} catch (Exception ex) {
16Console.Error.WriteLine(ex);
17}
18}
19 }


I compile this using the following:

$ gmcs -debug -out:ExceptionTest.exe ExceptionTest.cs
$ csc.exe /debug /out:ExceptionTest.exe ExceptionTest.cs

When I execute it under the .NET framework, I get the following stack trace:

$ ./ExceptionTest.exe
System.InvalidOperationException: Operation is not valid due to the current
state of the object.
   at Program.ThrowCatchRethrow() in
u:\Workspace\MonoTest\ExceptionTest.cs:line 8
   at Program.Main(String[] args) in
u:\Workspace\MonoTest\ExceptionTest.cs:line 14

When I execute it under Mono, I get the following:

$ mono --debug ./ExceptionTest.exe
System.InvalidOperationException: Operation is not valid due to the current
state of the object
  at Program.ThrowCatchRethrow () [0x0] in
U:\Workspace\MonoTest\ExceptionTest.cs:6

Here you can clearly see that the stack traces are *very* different.  In
fact, while it's nice that Mono shows line #06 as the place where the
exception is actually thrown, it loses the fact that line #14 was also part
of the stack at the time of the error.

The .NET framework shows line #08 as the place where the exception was
thrown, which is not ideal, however it includes line #14 which is what I
really want.

Is there a way we can get the stack traces to look more like the .NET
framework stack traces?  I actually find it significantly easier to track
down the location of a problem when presented with the .NET stack trace.

I know I can wrap and rethrow, but that loses the type of the initial
exception so it's not a feasible solution.  We're going to add a centralized
logging service and audit our code to try and track down these issues,
however, that's a rather painful way to go about this and we keep running
into this problem again and again.

Thanks,
Bryan
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Add constants for directory and file max length name? (on windows)

2010-12-14 Thread Jérôme De Cuyper

Did I get it completely wrong in my last message?

Thanks.

On Mon, Dec 13, 2010 at 11:25 PM, Jérôme De Cuyper <
jerome.decuy...@gmail.com> wrote:

> If I understand correctly, I should not be checking for this on the
> framework level but instead on the layer below it?
> Somehow I should catch the syscall errors and then throw a .NET exception,
> is that correct?
>
>
> On Mon, Dec 13, 2010 at 10:17 PM, Rodrigo Kumpera wrote:
>
>> Can't we check for syscall errors instead?
>>
>>
>> On Mon, Dec 13, 2010 at 10:43 PM, Jérôme De Cuyper <
>> jerome.decuy...@gmail.com> wrote:
>>
>>> I'm working on the following bug:
>>> https://bugzilla.novell.com/show_bug.cgi?id=
>>> 383909 
>>>
>>> On a windows box,
>>> the size of the name of file may not be longer than 260 and the size of the
>>> name of a directory must be smaller than 248 chars. I was thinking about
>>> adding a constant to the Path.cs file and then using it to apply
>>> restrictions when necessary (inside DirectoryInfo's constructor for
>>> instance). But I'm not sure that adding those constants is the best
>>> cross-platform way to handle this. Maybe it's is enough to use hard-coded
>>> values inside a "IsRunningOnWindows" conditional. Any thoughts?
>>>
>>> Jerome.
>>>
>>>
>>>
>>>
>>> On Mon, Dec 13, 2010 at 6:08 PM, Charles Strahan <
>>> charles.c.stra...@gmail.com> wrote:
>>>
 Jon,

 If I understand correctly, we'd have two options for using DLLImport:

  1.) Emit classes at runtime, containing the necessary native
 function adorned with the DLLImport attribute.
  2.) Use DLLImport/PInvoke to provide access to
 dlopen/LoadLibrary[Ex] and other similar functions, to dynamically
 load DLLs and invoke their functions.

 Is this correct? Option #1 seems relatively feasible, although we
 would give up the ability to use our RubyFFI implementation where
 Reflection.Emit is not available; Option #2 seems rather daunting.


 Thanks,

 -Charles

 >On Thu, 2010-08-19 at 10:35 -0700, Ryan Riley wrote:
 >> Has anyone created or investigated Mono support for libffi?
 >
 >Once upon a time, Mono used libffi directly.  It was removed in r724
 >(git SHA1 ID d0cd6059c1b2edad12eb67cb8e64b3cd187be1b1) on 2001-09-05
 >(and earlier).  Unfortunately, the commit message is useless, but iirc
 >the reason for removing it was because it was significantly slower than
 >what Mono could do itself.
 >
 >> I'd like to contribute this to help support Ruby-FFI for IronRuby.
 >
 >I imagine IronRuby doesn't require it's own FFI, it would just use the
 >usual .NET FFI of DllImport, no?
 >
 >As for supporting Ruby-FFI, perhaps you can extend the existing Mono
 FFI
 >support to support Ruby?  I don't know what would be involved...
 >
 > - Jon
 ___
 Mono-devel-list mailing list
 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-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

[Mono-dev] CS0584 Internal compiler error in gmcs.exe (master)

2010-12-14 Thread Tom Philpot

In membercache.cs.AddBaseType () line 219, if entry.Value.Count == 1, 
entry.Value is a MemberSpec[] which will cause the list.Add(ce) on Line 234 to 
fail.

Gmcs.exe fails with "CS0584: Internal compiler error: Collection is read-only" 
(in ecore.cs:433) when this case is encountered.

I ran across this error while compiling our code with Mono 2.9 from master 
today. I'm not sure how to reproduce the error, otherwise I'd have submitted a 
test case.


___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] CS0584 Internal compiler error in gmcs.exe (master)

2010-12-14 Thread Tom Philpot

Attached is a patch which should fix the issue.

Submitted under MIT/X11 license.

From: Tom Philpot mailto:tom.phil...@logos.com>>
Date: Tue, 14 Dec 2010 13:52:37 -0800
To: "mono-devel-l...@ximian.com" 
mailto:mono-devel-l...@ximian.com>>
Subject: [Mono-dev] CS0584 Internal compiler error in gmcs.exe (master)

In membercache.cs.AddBaseType () line 219, if entry.Value.Count == 1, 
entry.Value is a MemberSpec[] which will cause the list.Add(ce) on Line 234 to 
fail.

Gmcs.exe fails with "CS0584: Internal compiler error: Collection is read-only" 
(in ecore.cs:433) when this case is encountered.

I ran across this error while compiling our code with Mono 2.9 from master 
today. I'm not sure how to reproduce the error, otherwise I'd have submitted a 
test case.

diff --git a/mcs/mcs/membercache.cs b/mcs/mcs/membercache.cs
index 6561b28..9e409b3 100644
--- a/mcs/mcs/membercache.cs
+++ b/mcs/mcs/membercache.cs
@@ -231,7 +231,10 @@ namespace Mono.CSharp {
if (list.Contains (ce))
continue;

-   list.Add (ce);
+   if (list is MemberSpec[])
+   list = new List () 
{ list[0], ce };
+   else
+   list.Add (ce);
}
}
}
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

[Mono-dev] Too many open files when adding many embedded resources

2010-12-14 Thread Tom Philpot

Building Mono 2.9 from git master, we're encountering an issue where an 
assembly with lots of embedded resources (approx 4000), where gmcs is throwing 
"Too many open files exception".

The culprit seems to be that a new file handle is opened for every embedded 
resource when it's added. Mono 2.6 doesn't have this problem, so it appears to 
be a regression

Assembly.cs line 730:
if (res.IsEmbeded) {
var stream = File.OpenRead (res.FileName);
module.Builder.DefineManifestResource (res.Name, stream, res.Attributes);
} else {
Builder.AddResourceFile (res.Name, Path.GetFileName (res.FileName), 
res.Attributes);
}

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

[Mono-dev] trunk compile error, sgen-gc.c

2010-12-14 Thread KISHIMOTO, Makoto

Hello,

At my FreeBSD box, trunk build failed.
Errors are following.

$ gmake
(snip)
../../doltlibtool --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. 
-I../../../mono/mono/metadata -I../.. -I../../../mono -I../../../mono/mono 
-I../../../mono/libgc/include -I../../../mono/eglib/src -I../../eglib/src 
-DMONO_BINDIR=\"/usr/local/bin/\" -DMONO_ASSEMBLIES=\"/usr/local/lib\" 
-DMONO_CFG_DIR=\"/usr/local/etc\"  -DGC_FREEBSD_THREADS -DPLATFORM_BSD  
-DHAVE_SGEN_GC -DHAVE_MOVING_COLLECTOR -DHAVE_WRITE_BARRIERS -g -O2 
-fno-strict-aliasing -Wdeclaration-after-statement -g -Wall -Wunused 
-Wmissing-prototypes -Wmissing-declarations -Wstrict-prototypes  
-Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wno-cast-qual 
-Wwrite-strings -mno-tls-direct-seg-refs -MT 
libmonoruntimesgen_la-sgen-os-mach.lo -MD -MP -MF 
.deps/libmonoruntimesgen_la-sgen-os-mach.Tpo -c -o 
libmonoruntimesgen_la-sgen-os-mach.lo `test -f 'sgen-os-mach.c' || echo 
'../../../mono/mono/metadata/'`sgen-os-mach.c
mv -f .deps/libmonoruntimesgen_la-sgen-os-mach.Tpo 
.deps/libmonoruntimesgen_la-sgen-os-mach.Plo
../../doltlibtool --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. 
-I../../../mono/mono/metadata -I../.. -I../../../mono -I../../../mono/mono 
-I../../../mono/libgc/include -I../../../mono/eglib/src -I../../eglib/src 
-DMONO_BINDIR=\"/usr/local/bin/\" -DMONO_ASSEMBLIES=\"/usr/local/lib\" 
-DMONO_CFG_DIR=\"/usr/local/etc\"  -DGC_FREEBSD_THREADS -DPLATFORM_BSD  
-DHAVE_SGEN_GC -DHAVE_MOVING_COLLECTOR -DHAVE_WRITE_BARRIERS -g -O2 
-fno-strict-aliasing -Wdeclaration-after-statement -g -Wall -Wunused 
-Wmissing-prototypes -Wmissing-declarations -Wstrict-prototypes  
-Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wno-cast-qual 
-Wwrite-strings -mno-tls-direct-seg-refs -MT libmonoruntimesgen_la-sgen-gc.lo 
-MD -MP -MF .deps/libmonoruntimesgen_la-sgen-gc.Tpo -c -o 
libmonoruntimesgen_la-sgen-gc.lo `test -f 'sgen-gc.c' || echo 
'../../../mono/mono/metadata/'`sgen-gc.c
../../../mono/mono/metadata/sgen-gc.c: In function 
'mono_sgen_thread_info_lookup':
../../../mono/mono/metadata/sgen-gc.c:4863: warning: cast from pointer to 
integer of different size
../../../mono/mono/metadata/sgen-gc.c: In function 'suspend_handler':
../../../mono/mono/metadata/sgen-gc.c:5022: error: 'ucontext_t' undeclared 
(first use in this function)
../../../mono/mono/metadata/sgen-gc.c:5022: error: (Each undeclared identifier 
is reported only once
../../../mono/mono/metadata/sgen-gc.c:5022: error: for each function it appears 
in.)
../../../mono/mono/metadata/sgen-gc.c:5022: error: expected expression before 
')' token
../../../mono/mono/metadata/sgen-gc.c:5022: error: 'REG_RIP' undeclared (first 
use in this function)
../../../mono/mono/metadata/sgen-gc.c:5033: error: expected expression before 
')' token
../../../mono/mono/metadata/sgen-gc.c:5033: error: 'REG_RSP' undeclared (first 
use in this function)
../../../mono/mono/metadata/sgen-gc.c:5039: error: expected expression before 
')' token
../../../mono/mono/metadata/sgen-gc.c:5039: error: 'REG_RAX' undeclared (first 
use in this function)
../../../mono/mono/metadata/sgen-gc.c:5039: error: expected expression before 
')' token
../../../mono/mono/metadata/sgen-gc.c:5039: error: 'REG_RBX' undeclared (first 
use in this function)
../../../mono/mono/metadata/sgen-gc.c:5039: error: expected expression before 
')' token
../../../mono/mono/metadata/sgen-gc.c:5039: error: 'REG_RCX' undeclared (first 
use in this function)
../../../mono/mono/metadata/sgen-gc.c:5039: error: expected expression before 
')' token
../../../mono/mono/metadata/sgen-gc.c:5039: error: 'REG_RDX' undeclared (first 
use in this function)
../../../mono/mono/metadata/sgen-gc.c:5039: error: expected expression before 
')' token
../../../mono/mono/metadata/sgen-gc.c:5039: error: 'REG_RSI' undeclared (first 
use in this function)
../../../mono/mono/metadata/sgen-gc.c:5039: error: expected expression before 
')' token
../../../mono/mono/metadata/sgen-gc.c:5039: error: 'REG_RDI' undeclared (first 
use in this function)
../../../mono/mono/metadata/sgen-gc.c:5039: error: expected expression before 
')' token
../../../mono/mono/metadata/sgen-gc.c:5039: error: 'REG_RBP' undeclared (first 
use in this function)
../../../mono/mono/metadata/sgen-gc.c:5039: error: expected expression before 
')' token
../../../mono/mono/metadata/sgen-gc.c:5039: error: 'REG_R8' undeclared (first 
use in this function)
../../../mono/mono/metadata/sgen-gc.c:5039: error: expected expression before 
')' token
../../../mono/mono/metadata/sgen-gc.c:5039: error: 'REG_R9' undeclared (first 
use in this function)
../../../mono/mono/metadata/sgen-gc.c:5039: error: expected expression before 
')' token
../../../mono/mono/metadata/sgen-gc.c:5039: error: 'REG_R10' undeclared (first 
use in this function)
../../../mono/mono/metadata/sgen-gc.c:5039: error: expected expression before 
')' token
../../../mono/mono/metadata/sgen-gc.c:5039: error: 'REG_R11' undeclared (first 
use in this function

Re: [Mono-dev] Too many open files when adding many embedded resources

2010-12-14 Thread Geoff Norton

Tom,

  If you .Close and .Dispose the stream, does the issue resolve itself?

-g

On 2010-12-14, at 7:24 PM, Tom Philpot wrote:

> Building Mono 2.9 from git master, we're encountering an issue where an 
> assembly with lots of embedded resources (approx 4000), where gmcs is 
> throwing "Too many open files exception".
> 
> The culprit seems to be that a new file handle is opened for every embedded 
> resource when it's added. Mono 2.6 doesn't have this problem, so it appears 
> to be a regression
> 
> Assembly.cs line 730:
>   if (res.IsEmbeded) {
>   var stream = 
> File.OpenRead (res.FileName);
>   
> module.Builder.DefineManifestResource (res.Name, stream, res.Attributes);
>   } else {
>   Builder.AddResourceFile 
> (res.Name, Path.GetFileName (res.FileName), res.Attributes);
>   }
> 
> ___
> Mono-devel-list mailing list
> 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

Re: [Mono-dev] Too many open files when adding many embedded resources

2010-12-14 Thread Miguel de Icaza

Hello,

Building Mono 2.9 from git master, we're encountering an issue where an
> assembly with lots of embedded resources (approx 4000), where gmcs is
> throwing "Too many open files exception".
>
> The culprit seems to be that a new file handle is opened for every embedded
> resource when it's added. Mono 2.6 doesn't have this problem, so it appears
> to be a regression
>

The comment on the Save method says:

// According to MSDN docs, the stream is read during assembly save, not
earlier

So perhaps we need to change the compiler to load the assemblies in memory
after a certain number of resources have been loaded.

Miguel
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Mono/.NET Framework Very Different Stack Traces

2010-12-14 Thread jmalcolm


I cannot speak to changing the stack trace offered by Mono.

What I can say is that I tend to use inner exceptions in this situation to
get better insight into where the real problem lies.
-- 
View this message in context: 
http://mono.1490590.n4.nabble.com/Mono-NET-Framework-Very-Different-Stack-Traces-tp3087789p3088472.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

[Mono-dev] Mono Service crashs

Re: [Mono-dev] Mono Service crashs

[Mono-dev] Mono/.NET Framework Very Different Stack Traces

Re: [Mono-dev] Add constants for directory and file max length name? (on windows)

[Mono-dev] CS0584 Internal compiler error in gmcs.exe (master)

Re: [Mono-dev] CS0584 Internal compiler error in gmcs.exe (master)

[Mono-dev] Too many open files when adding many embedded resources

[Mono-dev] trunk compile error, sgen-gc.c

Re: [Mono-dev] Too many open files when adding many embedded resources

Re: [Mono-dev] Too many open files when adding many embedded resources

Re: [Mono-dev] Mono/.NET Framework Very Different Stack Traces

11 matches

Site Navigation

Mail list logo

Footer information