[Mono-dev] Ambiguous matching in method resolution
pablosantosluac at terra.es
pablosantosluac at terra.es
Wed May 31 17:03:40 EDT 2006
Well, and the server is not detecting any exception (we have a sink catching
all the possible raised exceptions).
So, I don't understand why, but it seems the client side is generating
different proxies depending on the server... and when they are both on
Linux/mono it fails...
The first problem I detected was solved renaming one method (even that it
was not a problem with the server in .NET), but now it seems lots more would
need to be renamed... :-(
----- Original Message -----
From: <pablosantosluac at terra.es>
To: "Rafael Teixeira" <monoman at gmail.com>
Cc: <mono-devel-list at lists.ximian.com>
Sent: Wednesday, May 31, 2006 10:55 PM
Subject: Re: [Mono-dev] Ambiguous matching in method resolution
> Well, I have a little more information now. I located the problem (I was
> not correctly handling the stack trace nor the --trace option), and it
> seems to have problems with certain methods defined in an interface used
> through remoting.
> What I don't understand is that the client works correctly on linux
> against a windows server (mono - .NET), but fails in the linux - linux
> scenario... Lots of remote method calls failing with the ambiguous
> matching exception...
> ----- Original Message -----
> From: "Rafael Teixeira" <monoman at gmail.com>
> To: <pablosantosluac at terra.es>
> Cc: <mono-devel-list at lists.ximian.com>
> Sent: Wednesday, May 31, 2006 8:49 PM
> Subject: Re: [Mono-dev] Ambiguous matching in method resolution
>> Pablo and mscorlib hackers,
>> Strange as that message is only found in the AmbiguousMatchException
>> default constructor, that is called inside Reflection, and inside
>> MonoType (an internal class) inside corlib.
>> So that exception would be normally thrown out, and generate a stack
>> trace. Unless the MonoType GetConstructorImpl method (probable
>> culprit) is being called from unmanaged code, that doesn't properly
>> handle exceptions (or can't in that particular situation).
>> It looks like there's a logic error in that method. If you are asking
>> for a parameterless constructor (by passing a null for the 'types'
>> array parameter), if it counts more than one constructor, REGARDLESS
>> OF THE NUMBER OF PARAMETERS EACH CONSTRUCTOR EXPECT, that matches the
>> bindingflags, it will throw that exception.
>> I think that it should first make sure it counts only methods that
>> expect the same number and type of parameters, before entering that
>> Some mscorlib hacker please take a look at that.
>> Probably you have more than one constructor with the same visibility
>> as the parameterless constructor in some of your classes, to cause
>> that exception, but as I think that is a common pattern, probably it
>> is combined with some other factors I can't guess without a
>> stacktrace, :(
>> Hope it helps,
>> On 5/31/06, pablosantosluac at terra.es <pablosantosluac at terra.es> wrote:
>>> I have an application that is correctly running with .NET, but as soon
>>> as I
>>> run it with mono (1.1.15) on Linux I get the following message:
>>> Error: Ambiguous matching in method resolution.
>>> I tried to recompile with mono on Linux with debug info, but I can't get
>>> more information, neither with --trace.
>>> What can I do to locate the problem?
>>> Mono-devel-list mailing list
>>> Mono-devel-list at lists.ximian.com
>> Rafael "Monoman" Teixeira
>> As I'm currently working a lot with Java and even fixing Java VMs
>> (JamVM/Kaffe) and GNU Classpath code, I think I may partly borrow the
>> title (Javaman) from my friend Bruno Souza and become the
>> MonoNJavaMan. Yeah, I may currently be crazier than usual...
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
More information about the Mono-devel-list