---- Reported by diltonm@McCOMSoft.com 2004-02-24 18:00:55 MST ----

Please fill in this template when reporting a bug, unless you know what 
you are doing.
Description of Problem:

Code that compiled cleanly under mono 0.29 now crashes with the following:

** (/usr/local/bin/mcs.exe:6165): WARNING **: Symbol 
file /usr/local/bin/mcs.exe has incorrect version (expected 36, got 35)
 
** ERROR **: file metadata.c: line 871 (mono_metadata_decode_row): 
assertion failed: (res_size == count)
aborting...
Killed

More info:
A) The mcs compiler with mcs --version reports 0.29.99.0 ??? That is in 
the assembly file too.

I do not have a way to reproduce without all my source. It is a project 
using WSE. Though the file in Test compiles cleanly for me. It has two of 
our own DLLs and I've re-compiled them succesfully. WSE both 1 and 2 
build cleanly. mono and mcs built cleanly.

Steps to reproduce the problem:
1. 
2. 
3. 

Actual Results:


Expected Results:


How often does this happen? 
Every single time.

Additional Information:

If there is anything else I can offer to assist in debugging this I'm 
happy to help.



---- Additional Comments From diltonm@McCOMSoft.com 2004-02-24 18:32:52 MST ----

This bug happens on Windows using the same Release, 0.30.1



---- Additional Comments From diltonm@McCOMSoft.com 2004-02-24 19:25:09 MST ----

Ok I isolated further and found that the following line was crashing 
the compiler:

//		private double _dTimerInterval = 1000 * Int32.Parse
(Utility.GetAppSetting("Time Scaler"));

This worked under previous versions of Mono. I tried changing the 
line to reference the method GetAppSetting and copied it locally to 
the class:

		public static string GetAppSetting(string sKey)
		{
			string sRet = "";

			lock(typeof(DCWatcher))
			{
				if( (sKey == null) || (sKey.Equals
("")) )
				{
					throw new Exception
("Argument validation exception");
				}

				try
				{
					AppSettingsReader appr = new 
System.Configuration.AppSettingsReader();
					sRet = (string)appr.GetValue
(sKey, typeof(string));
				}
				catch(Exception getsetex)
				{
					sRet = getsetex.Message;
				}
			}

			return sRet;
		}

This did not work so I tried the following:

//		private double _dTimerInterval = 1000 * Int32.Parse
(Utility.GetAppSetting("Time Scaler"));
		private int i = Int32.Parse(GetAppSetting("test"));
		private double _dTimerInterval = 1000;// * i;

and in the constructor:

			_dTimerInterval *= i;

and now it compiles successfully. It would be great if I don't have 
to propogate these changes to the rest of the project.

Dilton




---- Additional Comments From diltonm@McCOMSoft.com 2004-02-24 19:31:51 MST ----

Correction to my last...simply moving GetAppSettings from 
UtilityProject.Utility to the local class *does* work. Also I 
chenged the lock() value to be thorough.

This code worked in past versions of Mono so I'm not clear why it is 
an issue now? Is it no longer allowed to reference static code in 
another assembly?





---- Additional Comments From diltonm@McCOMSoft.com 2004-02-25 20:56:08 MST ----

Updated the platform information and summary fields.



---- Additional Comments From miguel@ximian.com 2004-02-27 01:18:09 MST ----

Can you provide a self-contained program that I can use to reproduce
the bug?



---- Additional Comments From diltonm@McCOMSoft.com 2004-02-27 04:18:50 MST ----

Created an attachment (id=165661)
Code to demonstrate 0.30.1 compiler crash




---- Additional Comments From diltonm@McCOMSoft.com 2004-02-27 04:19:38 MST ----

Ok, I've written a tiny project the last couple of hours to 
duplicate the bug and I'm attaching it as 30crash.zip. I wrote it on 
Windows but the bug in my actual project happened in both Windows 
and Linux.

After unzipping the contents use this line to build the utility .DLL 
module:

mcs -out:Utils.dll -t:module Utils.cs

And this for the main client .EXE module:

mcs Client.cs -r:System.Data.dll -r:System.Web.Services.dll -
r:System.Management.dll -r:Microsoft.Web.Services.dll" -
r:Utils/Utils.dll

-Dilton




---- Additional Comments From diltonm@McCOMSoft.com 2004-02-27 04:50:52 MST ----

Client.cs can be reduced to this:

using System;
using Utils;

namespace ClientTester
{
	public class MyClient
	{
		//This causes the crash.
		int i = Int32.Parse(Utilities.GetRefund());

		public MyClient() {}

		public static void Main()
		{
		}

		public string WillWeCrash()
		{
			return "Ok\n";
		}
	}
}



---- Additional Comments From miguel@ximian.com 2004-02-27 18:11:02 MST ----

This works with my copy of CVS, so am going to assume this is fixed
(using your Utils.dll, and the sample client).

Please try again with a snapshot.



---- Additional Comments From diltonm@McCOMSoft.com 2004-02-29 05:22:54 MST ----

I just downloaded yesterday's new main release mcs-0.30.2. It is 
still crashing using the above test project.

Tomorrow I will get any snapshots that are newer than yesterday's 
release and test again.

Notes:

1) The mcs-0.30.2.tar.gz file un-tars to mcs-0.30.1 ???

2) mcs --version reports 0.29.99

3) Please remember to build the supporting DLL Utils.dll then 
Client.cs.

4) I've reproduced this on several machines since the beginning and 
the latest was a pristine Fedora build.




---- Additional Comments From diltonm@McCOMSoft.com 2004-02-29 21:06:49 MST ----

Using a CVS snapshot I grabbed earlier today the test program 
compiles now...but my production project still fails in exactly the 
same spot, line 871 in metadata.c.




---- Additional Comments From miguel@ximian.com 2004-03-04 13:48:18 MST ----

I can not compile your program, since it uses the Microsoft WSE dll
which I do not have.  You said that you had the problem down to
one line for the C# compiler, can you share that?

On the other hand, this might be a problem with us accessing the WSE.dll

It would also be helpful if you run this in the debugger, and get a
stack trace of when the problem happens at the assertion point.



---- Additional Comments From diltonm@McCOMSoft.com 2004-03-04 18:01:33 MST ----

>> I can not compile your program, since it uses the Microsoft WSE dll
which I do not have.

I go into the mcs.0xxx/class/Microsoft.Web.Services folder and run
make. This outputs two Dlls to mcs.0.xxx/class/lib,
Microsoft.Web.Services.1.dll and 2.dll. I then copy the 2.dll to
Microsoft.Web.Services.dll in /usr/local/lib with the other Mono Dlls.


>> You said that you had the problem down to
one line for the C# compiler, can you share that?

On 2-24 at 19:25
Ok I isolated further and found that the following line was crashing 
the compiler:

//		private double _dTimerInterval = 1000 * Int32.Parse
(Utility.GetAppSetting("Time Scaler"));


>> On the other hand, this might be a problem with us accessing the
WSE.dll

It's possible but IIRC (and it's starting to get blurry) I had boiled
the problem code down ao almost nothing. I belive it centers around
calling a static routine in another DLL. Why my test code works not
but my main project still fails with the same error is surprising.
It's almost like a buffer is being overrun. Something DID change for
the better between 0.30.1 and the latest CVS version.


>> It would also be helpful if you run this in the debugger, and get a
stack trace of when the problem happens at the assertion point.

I've downloaded the debugger project from CVS and am attempting to
build it now. If I can produce some useful information then I'll post it.

Thanks.



---- Additional Comments From diltonm@McCOMSoft.com 2004-03-08 15:18:58 MST ----

When I run mcs inside mdb this is the information it provides:

Process @5 stopped at #0: 0x003d44b8 in Main+0x28 at Main:255.
0x003d44b8      push   %edi
 255                    bool ok = MainDriver (args);
Mono debugger

ALSO, the crash test code I wrote and attached earlier is crashing
with fairly recent CVS versions of the code. It seems to be random.
Regarding the test code, to reproduce it I recommend deleting
Utils.dll and Client.exe each time before attempting a new build.





---- Additional Comments From diltonm@McCOMSoft.com 2004-03-08 15:43:47 MST ----

gdb running mcs reports (at the first SIGPWR - which I have 'handled'
in  .gdbinit BTW ???):

#0  0x003ecc32 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1  0x0042be08 in sigsuspend () from /lib/tls/libc.so.6
#2  0x00ccb074 in GC_suspend_handler (sig=30) at linux_threads.c:695
#3  <signal handler called>
#4  0x003ecc32 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#5  0x0069554a in pthread_cond_timedwait@@GLIBC_2.3.2 ()
   from /lib/tls/libpthread.so.0
#6  0x00cb55de in _wapi_handle_wait_signal_handle (handle=0x3)
    at handles-private.h:87
#7  0x00cbd893 in WaitForSingleObject (handle=0x3, timeout=4294967295)
    at wait.c:95
#8  0x00c80ad0 in finalizer_thread (unused=0x0) at gc.c:528
#9  0x00c8aeae in start_wrapper (data=0x9e24fc0) at threads.c:232
#10 0x00cbd34f in timed_thread_start_routine (args=0x9e24fd8)
    at timed-thread.c:115
#11 0x00ccc0a3 in GC_start_routine (arg=0x9db6d40) at linux_threads.c:1663
#12 0x0069279c in start_thread () from /lib/tls/libpthread.so.0
#13 0x004df27a in clone () from /lib/tls/libc.so.6

After 'continue' I get this:

(gdb) where
#0  0x003ecc32 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1  0x0042b98f in raise () from /lib/tls/libc.so.6
#2  0x0042d302 in abort () from /lib/tls/libc.so.6
#3  0x0088baa7 in GC_abort (msg=0x8b1445 "sem_wait in handler failed")
    at misc.c:1044
#4  0x008865d9 in linux_stop_world () at linux_threads.c:986
#5  0x00886604 in GC_stop_world () at linux_threads.c:1007
#6  0x008815de in GC_stopped_mark (stop_func=0x880ed0
<GC_never_stop_func>)
    at alloc.c:479
#7  0x008812fa in GC_try_to_collect_inner (
    stop_func=0x880ed0 <GC_never_stop_func>) at alloc.c:362
#8  0x00882054 in GC_collect_or_expand (needed_blocks=1,
ignore_off_page=0)
    at alloc.c:981
#9  0x00882246 in GC_allocobj (sz=4, kind=1) at alloc.c:1056
#10 0x008876fa in GC_generic_malloc_inner (lb=12, k=1) at malloc.c:134
#11 0x008877f7 in GC_generic_malloc (lb=12, k=1) at malloc.c:190
#12 0x00887a99 in GC_malloc (lb=12) at malloc.c:295
#13 0x0087921f in mono_g_hash_table_insert (hash_table=0x8e07f00,
    key=0xbeb93dc0, value=0x8fd9e40) at mono-hash.c:301
#14 0x0082ca87 in mono_ldstr (domain=0x8e0aed8, image=0x539998, idx=0)
    at object.c:2175
#15 0x007e2094 in mono_method_to_ir (cfg=0x8f74598, method=0x8f50888,
    start_bblock=0x8f6d6f0, end_bblock=0x8f6d788, locals_offset=0,
---Type <return> to continue, or q <return> to quit---
    return_var=0x0, dont_inline=0x8f4ba4c, inline_args=0x0,
inline_offset=0,
    is_virtual_call=0) at mini.c:3857
#16 0x007ee97a in mini_method_compile (method=0x8f50888, opts=0,
domain=0x0,
    run_cctors=0, parts=0) at mini.c:7419
#17 0x007ef26e in mono_jit_compile_method_inner (method=0x8f50888)
    at mini.c:7722
#18 0x007ef453 in mono_jit_compile_method_with_opt (method=0x8f50888,
    opt=84363) at mini.c:7774
#19 0x007ef48d in mono_jit_compile_method (method=0x8f50888) at
mini.c:7784
#20 0x00829d13 in mono_compile_method (method=0x8f50888) at object.c:187
#21 0x0081b480 in x86_magic_trampoline (eax=150259760, ecx=0,
edx=150276232,
    esi=0, edi=150208248, ebx=9256176, code=0x0, m=0x8f50888) at
tramp-x86.c:97
#22 0x08e704cf in ?? ()
#23 0x08f4c830 in ?? ()

HTH -Dilton



---- Additional Comments From diltonm@McCOMSoft.com 2004-04-01 21:23:15 MST ----

The test code posted previously still works - it crashes the compiler
successfully. The symtoms remain unchanged.

I'm now wondering if I made a mistake to try Mono, perhaps our company
should switch to Java?




---- Additional Comments From miguel@ximian.com 2004-04-11 00:34:36 MST ----

Your Utils.dll in fact breaks the compiler, it might have been
a bug on the metadata generator when you compiled it.

If I rebuild the code (Utils.dll) it will work.

Now, that being said, am worried that you might expect a few
of those assemblies to be completed.  In particular, 
Microsoft.Web.Services is nowhere complete, and Microsoft has not
release a stable version of that API either, so depending on that
to work on Mono is a bit of a stretch.

The details on what Mono will support in 1.0 are available here:

http://www.go-mono.com/mono-roadmap.html





---- Additional Comments From diltonm@McCOMSoft.com 2004-04-12 21:38:20 MST ----

Delete Utils.dll, rebuild it, then rebuild the Client.cs. It WILL 
crash.




---- Additional Comments From miguel@ximian.com 2004-04-14 02:05:47 MST ----

It works with CVS, and very likely 0.31 as released:

mono$ mcs -target:library Utils.cs
Compilation succeeded
mono$ mono Client.cs -r:Utils.dll
cannot open assembly Client.cs
mono$ mcs Client.cs -r:Utils.dll
Client.cs(4) error CS0246: The namespace `System.Data' can not be
found (missing assembly reference?)
    Try using -r:System.Data
Client.cs(7) error CS0246: The namespace `System.Web.Services' can not
be found (missing assembly reference?)
    Try using -r:System.Web.Services
Client.cs(8) error CS0246: The namespace
`System.Web.Services.Protocols' can not be found (missing assembly
reference?)
Client.cs(16) error CS0246: The namespace `System.Management' can not
be found (missing assembly reference?)
Client.cs(17) error CS0246: The namespace `Microsoft.Web.Services' can
not be found (missing assembly reference?)
Client.cs(18) error CS0246: The namespace
`Microsoft.Web.Services.Dime' can not be found (missing assembly
reference?)
Compilation failed: 6 error(s), 0 warnings
mono$ mcs Client.cs -r:Utils.dll -r:System.Web.Services
-r:Microsoft.Web.Services
Client.cs(4) error CS0246: The namespace `System.Data' can not be
found (missing assembly reference?)
    Try using -r:System.Data
Client.cs(16) error CS0246: The namespace `System.Management' can not
be found (missing assembly reference?)
Compilation failed: 2 error(s), 0 warnings
mono$ mcs Client.cs -r:Utils.dll -r:System.Web.Services
-r:Microsoft.Web.Services -r:System.Data
Client.cs(16) error CS0246: The namespace `System.Management' can not
be found (missing assembly reference?)
Compilation failed: 1 error(s), 0 warnings
mono$ mcs Client.cs -r:Utils.dll -r:System.Web.Services
-r:Microsoft.Web.Services -r:System.Data -r:System.Management
Compilation succeeded
mono$ mono --version
Mono JIT compiler version 0.31.99, (C) 2002-2004 Novell, Inc and
Contributors. www.go-mono.com
	TLS:           NPTL
	GC:            Included Boehm (with typed GC)
	SIGSEGV      : altstack
	Globalization: ICU

Please provide the information i requested, there is not much that
can be done otherwise.

What OS, distro, flags?




---- Additional Comments From diltonm@McCOMSoft.com 2004-04-14 02:38:56 MST ----

> Please provide the information i requested, there is not much that
can be done otherwise.

What information sir, you said requested, that's past tense? I've 
worked my butt off for free to provide you with enough information.


> What OS, distro, flags?

Fedora 1.0 Core (no updates since Fedora has issues getting then 
downloaded foor reasons that are not clear, this ues to work for me 
in earlier versions of RedHat before they went different paths).

Here is the line I use to build:

mcs Client.cs -r:System.Data.dll -r:System.Web.Services.dll -
r:System.Management.dll -r:"\Program Files\Microsoft WSE\v2.0
\Microsoft.Web.Services.dll" -r:Utils/Utils.dll

Also the exact same crash happens on Windows XP with updates (since 
Microsoft has their updated system working well).

I'm using Mono 0.31 and NO I'm not hopping on the 'latest CVS works' 
bandwagon. I did that before, found out it was still crashing and 
had to re-open the bug.

Perhaps the fact that I've re-opened this same bug twice now and has 
a history a mile long should serve as some indication that it should 
be taken seriously?

Dilton







---- Additional Comments From duncan@ximian.com 2004-04-14 03:08:18 MST ----

This is taken very seriously.

How did you install Mono? Did you build on your own, or are you using
an RPM?

On NPTL-enabled systems, the current released version of Mono 0.31
RPMs contain a problem -- they're not built with NPTL enabled. I'll
try to fix it this week.

If you installed from source, did you make sure you always installed
to the same prefix? I noticed from the first post that you have this
error:

file /usr/local/bin/mcs.exe has incorrect version (expected 36, got 35)

This is a sign of a mis-managed installation.

Have you been using the same setup since the time when you first
reported this bug? You may very well have stale files on your machine.

As for the information Miguel mentioned, it's specifically:

mono$ mono --version
Mono JIT compiler version 0.31.99, (C) 2002-2004 Novell, Inc and
Contributors. www.go-mono.com
	TLS:           NPTL
	GC:            Included Boehm (with typed GC)
	SIGSEGV      : altstack
	Globalization: ICU



---- Additional Comments From diltonm@McCOMSoft.com 2004-04-14 17:31:38 MST ----

> This is taken very seriously.

Thanks.

> How did you install Mono? Did you build on your own, or are you 
using an RPM?

Most of the time I build and install from source but I've tried from 
RPMs on one machine. I've duplicated this bug on several machines 
all running the default Fedora 1 Core as well as Windows XP.

I've tried the posted version on www.go-mono.com and CVS snapshots.

It fails with exactly the same error on Windows XP and Fedora 1 Core 
and has been since I posted the bug originally.

It WAS working in 0.29 for sure, and even 0.28 IIRC.

> Have you been using the same setup since the time when you first
reported this bug? You may very well have stale files on your 
machine.

If you read through the history you will see that I've duplicated 
this bug on several machines of which, well, several were plain 
vanilla, no prior hint of Mono. I will detail for you the procedure 
I follow rigidly:

On Fedora - I download the tar ball, read README and INSTALL, follow 
the instructions, try to compile the sample code and then the error 
that I've been reporting pops up.

On Windows - I uninstall Mono from Add/Remove programs, download and 
install the latest then try my test program and get exactly the same 
error.

> As for the information Miguel mentioned, it's specifically:

On Fedora here is my printout:

[xxxxx@xxxxxxx 30crash]# mono --version
Mono JIT compiler version 0.31, (C) 2002-2004 Novell, Inc and 
Contributors. www.go-mono.com
        TLS:           NPTL
        GC:            Included Boehm (with typed GC)
        Globalization: none
[xxxxx@xxxxxxx 30crash]#

On Windows XP:

C:\>mono --version
Mono JIT compiler version 0.31, (C) 2002-2004 Novell, Inc and 
Contributors. www
go-mono.com
        TLS:           normal
        GC:            System Boehm (no typed GC available)
        Globalization: ICU
C:\>

Yes the version seems to be slightly different and no I'm not going 
to try the latest CVS (again) until someone there does what all we 
software engineers do to close bugs properly and that is prove there 
that you can delete Utils.dll and rebuild it then Client.cs and the 
bug does not happen and do this on Fedora 1 (no updates) and Windows 
XP (all updates) and do it sucessfully (deleting Utils.dll each 
time) for several times in a row.

This is a work blocking, compiler crash bug gentlemen, one that has 
slipped through the past several releases even though your team was 
made aware of it by me.

Dilton




---- Additional Comments From vladimir@pobox.com 2004-04-15 05:57:34 MST ----

(Randomly came across this bug and figured I'd try to duplicate.)

The crash occurs only with the included Utils.dll (note:
Microsoft.Web.Services.dll is the mono stub impl, dll #2)

vladimir@thunder[1061]% mcs Client.cs -r:System.Data.dll
-r:System.Web.Services.dll -r:System.Management.dll -r:Utils/Utils.dll
-r:Microsoft.Web.Services.dll

** ERROR **: file metadata.c: line 870 (mono_metadata_decode_row):
assertion failed: (res_size == count)
aborting...
/usr/local/bin/mcs: line 2:  2409 Aborted                
/usr/local/bin/mono /usr/local/bin/mcs.exe "$@"

Rebuilding Utils.dll makes the problem go away.  On the original
Utils.dll, peverify reports:

vladimir@tornado[5]% peverify Utils.dll
Microsoft (R) .NET Framework PE Verifier  Version 1.1.4322.573
Copyright (C) Microsoft Corporation 1998-2002. All rights reserved.

[IL]: Error: The module '' was expected to contain an assembly manifest.
1 Errors Verifying Utils.dll

A rebuilt Utils.dll verifies with no problems.  Run peverify on a
Utils.dll that you build.  If it has the above problem, then something
is wrong with your mono install -- mcs CVS as of about a week ago does
not have the problem; I don't have 0.31 installed anywhere to test. 
So, the bug here is really that mono should give a better error
message when it tries to load a corrupt assembly.. specifically, in
this case, one with MONO_TABLE_ASSEMBLY table in the image set to 0's. 



---- Additional Comments From diltonm@McCOMSoft.com 2004-04-15 11:42:00 MST ----

Thanks for taking a look at this. After Client.cs built ok, did you 
go back and delete Utils.dll, rebuild it, then try to rebuild 
Client.cs?




---- Additional Comments From vladimir@pobox.com 2004-04-15 19:17:46 MST ----

vladimir@thunder[1062]% mcs Client.cs /r:System.Data
/r:System.Web.Services /r:System.Management
/r:Microsoft.Web.Services.dll /r:Utils/Utils.dll
                                                                     
          
** ERROR **: file metadata.c: line 870 (mono_metadata_decode_row):
assertion failed: (res_size == count)
aborting...
/usr/local/bin/mcs: line 2:  2476 Aborted                
/usr/local/bin/mono /usr/local/bin/mcs.exe "$@"
vladimir@thunder[1063]% cd Utils
vladimir@thunder[1064]% rm Utils.dll
vladimir@thunder[1065]% mcs /target:library /out:Utils.dll Utils.cs
Compilation succeeded
vladimir@thunder[1066]% cd ..
vladimir@thunder[1067]% mcs Client.cs /r:System.Data
/r:System.Web.Services /r:System.Management
/r:Microsoft.Web.Services.dll /r:Utils/Utils.dll
Compilation succeeded
vladimir@thunder[1068]% cd Utils
vladimir@thunder[1069]% rm Utils.dll
vladimir@thunder[1070]% mcs /target:library /out:Utils.dll Utils.cs
Compilation succeeded
vladimir@thunder[1071]% cd ..
vladimir@thunder[1072]% mcs Client.cs /r:System.Data
/r:System.Web.Services /r:System.Management
/r:Microsoft.Web.Services.dll /r:Utils/Utils.dll
Compilation succeeded




---- Additional Comments From miguel@ximian.com 2004-04-22 00:55:38 MST ----

This bug is fixed.



---- Additional Comments From diltonm@McCOMSoft.com 2004-04-22 01:29:43 MST ----

Note to observers: in 0.31 which is the currently public release it 
is broken. CVS du jour might or might not work.


Imported an attachment (id=165661)

Unknown bug field "cf_op_sys_details" encountered while moving bug
   <cf_op_sys_details>Linux and Windows</cf_op_sys_details>
Unknown bug field "cf_version_details" encountered while moving bug
   <cf_version_details>0.31</cf_version_details>