System.StackOverflowException when using ZeroC Ice 3.4.2 on Mono 2.10.x

in Bug Reports
I have reported this bug in the Mono bug tracking system here:
Bug 2449 – System.StackOverflowException when using ZeroC Ice 3.4.2 on Mono 2.10.x
However, one of the developers suggested to file a bug in these forums as well, as you likely have more information to resolve it.
Take a look please at the bug link for the complete bug report. I've also attached a file with a trace of the exception. The problem seems to reside in this method:
IceInternal.AssemblyUtil.loadReferencedAssemblies (System.Reflection.Assembly)
Bug 2449 – System.StackOverflowException when using ZeroC Ice 3.4.2 on Mono 2.10.x
However, one of the developers suggested to file a bug in these forums as well, as you likely have more information to resolve it.
Take a look please at the bug link for the complete bug report. I've also attached a file with a trace of the exception. The problem seems to reside in this method:
IceInternal.AssemblyUtil.loadReferencedAssemblies (System.Reflection.Assembly)
0
Comments
Thanks for reporting this. If it is a Mono bug, we'll try to find a workaround that we can include in the next release.
Regards,
Mark
I've been doing some testing with Mono 2.10.8 on SLES 11 but haven't been able to reproduce the problem you described. Of course, the problem may be dependent on your application structure, such as how many assemblies are used in your server, where the Slice-generated code is located, and so on.
Would you be able to provide a small test case that we can use to reproduce this problem?
If not, can you describe in detail the assembly structure used by your server?
Thanks,
Mark
I just installed Mono 2.10.8 on Fedora and I was able to reproduce the problem. I'm planning to upload the source code of my app soon so you can play with it. Will let you know when it's ready.
Thank you!
Milton.
Have you prepared your codes yet? If so, i would like to run on my machine and try to find out what happens.
Thanks..
You can download the source code from this URL. These are the steps to reproduce the problem:
Let me know if you have any problem. And sorry again for the long delay.
Thank you.
Maybe for you this is low priority, what I understand, but I only need to know if this is going to be tested or if it was marked as low priority. This issue will be blocking me soon from releasing my application, and I need to evaluate other alternatives if necessary.
I'm available to provide more information if needed, or to debug Ice internally, but I need some clue.
Thank you.
I'll admit this hasn't been a high priority for us, for several reasons:
- You're using an unsupported version of Mono, on an unsupported platform.
- The example you provided is large and complex.
- We already tried to reproduce the problem using Mono 2.10.x on a supported platform, but couldn't duplicate it.
The quickest way to get this resolved is for you to provide a small example that we can use to reproduce the problem. Please also tell us the exact versions of Mono and operating system that you are using.Regards,
Mark
I'll try to trace down the problem and make a small test for you.
One more thing: in my first post in this thread, I put a link to the Mono's Bugzilla bug I reported. In that bug there is a log file attached, where you can see why the Stackoverflow exception is thrown. Maybe you can take a quick look at it and give me a clue about where could be the problem. This is the stack trace:
In line 1, the code tests to see if the dictionary contains an entry for the value of the AssemblyName.FullName property. Later, on line 2, the code adds an entry to this dictionary using the Assembly.FullName property. The code assumes that these two properties are identical. If they are not identical, we could be in trouble.
First, I would add a couple of trace statements to the method, such as:
If it turns out that the two values of FullName are different, I would probably consider that to be a bug in Mono (since it's not a problem in .NET for Windows).
Let us know what you find out.
Regards,
Mark
This was the problem: my application uses Npgsql.dll (PostgreSQL provider for .NET), which depends on Mono.Security.dll. The latter was copied to my application output directory, and it's version is 2.0.0.0. However, Assembly.Load was loading Mono.Security version 4.0.0.0. And here you have different values for AssemblyName.FullName and Assembly.FullName.
I guess this is not a problem with Mono. I bet my application was working on Windows because there is no Mono.Security installed in the GAC there, as it is in Ubuntu (where the problem was reproducible).
If you are going to fix this problem by making that code more robust, I can provide more details and maybe a small test case.
Regards,
Milton
Glad to hear that you solved the problem. I would be interested in seeing your solution.
Regards,
Mark