[Mono-dev] Ambiguous matching in method resolution
pablosantosluac at terra.es
pablosantosluac at terra.es
Wed May 31 17:41:31 EDT 2006
And more info yet.
The methods that seem to have trouble are the following:
- The server is "publishing" several interfaces under different "service
names" by remoting.
- There are methods with the same name and different signatures on different
- These methods are the ones causing trouble (not even overloaded methods on
the same interface, but methods with the same name on different ones)
We are publishing the objects (typecasting to the interfaces we want to
export) through the Marshall facility (not RegisterWellKnown...) so we
control the objects lifetime ourselves...
----- Original Message -----
From: <pablosantosluac at terra.es>
Cc: <mono-devel-list at lists.ximian.com>
Sent: Wednesday, May 31, 2006 11:03 PM
Subject: Re: [Mono-dev] Ambiguous matching in method resolution
> 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 any
>>>> 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
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
More information about the Mono-devel-list