Re: [Mono-dev] StackOverflow on System.Delegate.Equals

[pwo]

Hello,

I'm afraid this wasn't our case, because after updating mono to version
2.10.2 (from branch not a tarball) we still get reports that stack overflow
occurs. 

Does anybody have any idea how can I find cause of this problem?

Best Regards,
Pawel


Zoltan Varga wrote:
> 
> Hi,
> 
>   This was probably caused by:
> 
> https://bugzilla.novell.com/show_bug.cgi?id=687902
> 
> which is now
> fixed.
> 
> Zoltan
> 
> ___
> Mono-devel-list mailing list
> Mono-devel-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
> 


--
View this message in context: 
http://mono.1490590.n4.nabble.com/StackOverflow-on-System-Delegate-Equals-tp3411024p3502013.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

Re: [Mono-dev] Cross-Appdomain remoting

[Michael Mudge]

Ah!  The idea of changing the lifetime was enough info for me to find the cause.

Hm, I could swear I saw a difference in behavior between .NET and
Mono, but my simplified test case revealed an identical error (with
slightly different text) in .NET - that led me to
InitializeLifetimeService.

I overrode InitializeLifetimeService on the MarshalByRef objects and
returned null - this prevents the objects from expiring.  Thanks for
the reply!

- Kipp

On Thu, May 5, 2011 at 4:49 PM, Robert Jordan  wrote:
> Hi,
>
> On 05.05.2011 22:11, Michael Mudge wrote:
>> I'm seeing strange behavior on our device - AppDomain A has launched
>> AppDomain B, and wired the DomainUnloaded event.  I'm seeing that
>> RemotingServices.DisposeIdentity is being called after 5 minutes, and
>> then when AppDomain B unloads itself and the unload event is fired, I
>> get this error:
>>
>> Unhandled Exception: System.Runtime.Remoting.RemotingException: Server
>> for uri '6c9364e7_bf92_4f6d_950d_9cfc5c9a372d/b4c91032_2.rem' not
>> found
>>
>> Server stack trace:
>>    at System.Runtime.Remoting.Proxies.RealProxy.GetAppDomainTarget ()
>> [0x0] in:0
>>    at (wrapper xdomain-dispatch)
>> Manager.Shells.WAppServer:HandleDomainUnload
>> (object,byte[]&,byte[]&,string)
>>
>> I *think* that the problem is that the domain unload can't find A.
>>
>> I *think* that the object that can't be found is supposed to be
>> automatically recreated - am I right?  If that's true, I'm guessing
>
> The proxy won't be recreated. If you want to prevent it from
> being disposed, you should either change its lifetime (via
> app.config's  element) or call/poll
> a method periodically.
>
>> that this can't be done when an AppDomain is being unload...  Is that
>> true?  Where should I start looking to solve this?  Can someone
>> provide a clearer explanation of how this all works?
>
> Please explain first (preferably with code) what you're trying
> to achieve.
>
> Robert
>
> ___
> 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] Adding AES-NI support

[Joe Dluzen]

Hi all,

I'm looking at adding Intel AES-NI support to Mono. Most of the actual
code that does useful stuff is done by other people (on what looks
like a very liberal license), so I'm just gluing it all together. Does
the runtime currently have methods for determining the instruction
sets that the CPU supports? I'd imagine that you'd want to use the
accelerated implementation first if available, and if not, fall back
to the current default, which I think is RijndaelManaged.

Comments?

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

Re: [Mono-dev] Adding AES-NI support

[Sebastien Pouliot]

Hello Joe,

On Fri, 2011-05-06 at 17:02 -0400, Joe Dluzen wrote:
> Hi all,
> 
> I'm looking at adding Intel AES-NI support to Mono. Most of the actual
> code that does useful stuff is done by other people (on what looks
> like a very liberal license), so I'm just gluing it all together.

That sounds great :)

>  Does
> the runtime currently have methods for determining the instruction
> sets that the CPU supports? I'd imagine that you'd want to use the
> accelerated implementation first if available, and if not, fall back
> to the current default, which I think is RijndaelManaged.

There's already a built-in mechanism for this (available in both MS.NET
and Mono). You can replace everything that correctly (i.e. use the
factory methods) use Rjindael/Aes (or most cryptographic
implementations) by using machine.config file.

As such you only need to concentrate on your own, AES-NI,
implementation. I.e. something that derive from Rjindael or Aes.

Sebastien

p.s. at some point, once we get a few different implementations, we'll
likely want something to help users. I got some notes about that... I'll
try to dig them out this weekend and post them.

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

Re: [Mono-dev] scratchbox devkit?

[Liam Staskawicz]

Actually, I just had a chance to look at the ./configure script and it looks 
like there is a fair amount of support in there for cross compiling: the 
targets powerpc64-ps3-linux-gnu, powerpc64-xbox360-linux-gnu, x86_64-*-nacl, 
armv7l-unknown-linux-gnueabi*, and armv5tel-unknown-linux-gnueabi* all seem to 
have entries in the ` if test "x$host" != "x$target"; ` condition.

I was wondering if you could provide a bit more detail about the state of 
support for these targets (happily, mine is on the list). Are these not 
actively maintained, or not known to work, or perhaps covered by some other 
disclaimer? 

Thanks!
Liam

On Wednesday, May 4, 2011 at 9:00 AM, Liam Staskawicz wrote: 
> Ah, also - http://www.mono-project.com/Mono:ARM recommends using scratchbox 
> to build mono for ARM. Would be nice to clarify there as well, if possible.
> 
> Thanks,
> Liam
> On Wednesday, May 4, 2011 at 8:06 AM, Liam Staskawicz wrote:
> > OK, thanks!
> > 
> > Liam
> > On Wednesday, May 4, 2011 at 2:05 AM, Zoltan Varga wrote:
> > > Hi,
> > > 
> > >  We recommend compiling on the device itself if possible, using distcc 
> > > for example. Our configure scripts etc. are not really written with 
> > > cross-compilation in mind.
> > > 
> > >  Zoltan
> > > 
> > > On Wed, May 4, 2011 at 9:04 AM, Liam Staskawicz  wrote:
> > > > Hi, 
> > > > 
> > > > I'm just getting set up trying to cross compile mono for an ARM target 
> > > > using scratchbox. The wiki page at 
> > > > http://www.mono-project.com/Scratchbox mentions a mono devkit, but the 
> > > > only address is to svn://anonsvn.mono-project.com which now redirects 
> > > > to github, and I can't find the subproject mentioned (garmono?) 
> > > > anywhere in the sources on github. 
> > > > 
> > > > Did this component not survive the transition to github? Anybody have 
> > > > any tips on where to find it if it still exists?
> > > > 
> > > > Of course this is coming from the perspective of somebody searching 
> > > > high and low for info, but if the maintainer is still around it would 
> > > > be nice to update the wiki page, even to say that it's out of date :) 
> > > > 
> > > > Thanks!
> > > > Liam
> > > > 
> > > > 
> > > > ___
> > > >  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] scratchbox devkit?

[Zoltan Varga]

Hi,

  That code is actually for cross AOT, i.e. using a runtime running on x86
to generate AOT code for arm, for example. I.e. it checks host and target,
and not host and build.

 Zoltan

On Sat, May 7, 2011 at 3:51 AM, Liam Staskawicz  wrote:

>  Actually, I just had a chance to look at the ./configure script and it
> looks like there is a fair amount of support in there for cross compiling:
> the targets powerpc64-ps3-linux-gnu, powerpc64-xbox360-linux-gnu, 
> x86_64-*-nacl,
> armv7l-unknown-linux-gnueabi*, and armv5tel-unknown-linux-gnueabi* all
> seem to have entries in the ` if test "x$host" != "x$target"; ` condition.
>
> I was wondering if you could provide a bit more detail about the state of
> support for these targets (happily, mine is on the list). Are these not
> actively maintained, or not known to work, or perhaps covered by some other
> disclaimer?
>
> Thanks!
> Liam
>
>  On Wednesday, May 4, 2011 at 9:00 AM, Liam Staskawicz wrote:
>
>  Ah, also - http://www.mono-project.com/Mono:ARM recommends using
> scratchbox to build mono for ARM. Would be nice to clarify there as
> well, if possible.
>
> Thanks,
> Liam
>
> On Wednesday, May 4, 2011 at 8:06 AM, Liam Staskawicz wrote:
>
>  OK, thanks!
>
> Liam
>
> On Wednesday, May 4, 2011 at 2:05 AM, Zoltan Varga wrote:
>
> Hi,
>
>   We recommend compiling on the device itself if possible, using distcc for
> example. Our configure scripts etc. are not really written with
> cross-compilation in mind.
>
>   Zoltan
>
> On Wed, May 4, 2011 at 9:04 AM, Liam Staskawicz  wrote:
>
>  Hi,
>
> I'm just getting set up trying to cross compile mono for an ARM target
> using scratchbox. The wiki page at 
> http://www.mono-project.com/Scratchboxmentions a mono devkit, but the only 
> address is to
> svn://anonsvn.mono-project.com which now redirects to github, and I can't
> find the subproject mentioned (garmono?) anywhere in the sources on github.
>
> Did this component not survive the transition to github? Anybody have any
> tips on where to find it if it still exists?
>
> Of course this is coming from the perspective of somebody searching high
> and low for info, but if the maintainer is still around it would be nice to
> update the wiki page, even to say that it's out of date :)
>
> Thanks!
> Liam
>
> ___
> 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