---- Reported by grendello@gmail.com 2006-12-18 14:57:18 MST ----

Current svn head throws the following exception with xsp2 serving the 
attached file:

System.NullReferenceException: Object reference not set to an instance of 
an object
  at System.Web.Compilation.AspParser.GetServerTag 
(System.Web.Compilation.TagType& tagtype, System.String& id, 
System.Web.Compilation.TagAttributes& attributes) [0x00149] in /usr/src/
tmp/mono/mcs/class/System.Web/System.Web.Compilation/AspParser.cs:457 
  at System.Web.Compilation.AspParser.GetTag 
(System.Web.Compilation.TagType& tagtype, System.String& id, 
System.Web.Compilation.TagAttributes& attributes) [0x00044] in /usr/src/
tmp/mono/mcs/class/System.Web/System.Web.Compilation/AspParser.cs:241 
  at System.Web.Compilation.AspParser.Parse () [0x000cc] in /usr/src/tmp/
mono/mcs/class/System.Web/System.Web.Compilation/AspParser.cs:153 
  at System.Web.Compilation.AspGenerator.Parse (System.String 
file) [0x00007] in /usr/src/tmp/mono/mcs/class/System.Web/
System.Web.Compilation/AspGenerator.cs:252 
  at System.Web.Compilation.AspGenerator.Parse () [0x00000] in /usr/src/
tmp/mono/mcs/class/System.Web/System.Web.Compilation/AspGenerator.cs:269 
  at System.Web.Compilation.AspGenerator.GetCompiledType () [0x00054] in /
usr/src/tmp/mono/mcs/class/System.Web/System.Web.Compilation/
AspGenerator.cs:283 
  at System.Web.UI.PageParser.CompileIntoType () [0x00007] in /usr/src/tmp/
mono/mcs/class/System.Web/System.Web.UI/PageParser.cs:341 
  at System.Web.UI.TemplateControlParser.GetCompiledInstance () [0x00000] 
in /usr/src/tmp/mono/mcs/class/System.Web/System.Web.UI/
TemplateControlParser.cs:72 
  at System.Web.UI.PageParser.GetCompiledPageInstance (System.String 
virtualPath, System.String inputFile, System.Web.HttpContext 
context) [0x00009] in /usr/src/tmp/mono/mcs/class/System.Web/System.Web.UI/
PageParser.cs:101 
  at System.Web.UI.PageHandlerFactory.GetHandler (System.Web.HttpContext 
context, System.String requestType, System.String url, System.String 
path) [0x00000] in /usr/src/tmp/mono/mcs/class/System.Web/System.Web.UI/
PageHandlerFactory.cs:40 
  at System.Web.HttpApplication.GetHandler (System.Web.HttpContext 
context) [0x00059] in /usr/src/tmp/mono/mcs/class/System.Web/System.Web/
HttpApplication.cs:1124 
  at System.Web.HttpApplication+<>c__CompilerGenerated3.MoveNext 
() [0x006ad] in /usr/src/tmp/mono/mcs/class/System.Web/System.Web/
HttpApplication.cs:895 

When line AspParser.cs:457 is replaced with:

                      if (databinding)
                              tagtype = TagType.DataBinding;
                      else if (varname)
                              tagtype = TagType.CodeRenderExpression;
                      else
                              tagtype = TagType.CodeRender;

or the following line is put before line 457

Console.WriteLine("databinding == {0};varname == {1}", databinding, 
varname);

the exception does not occur. The problem first showed up sometime last 
week, I can't tell exactly when, though.



---- Additional Comments From grendello@gmail.com 2006-12-18 14:57:48 MST ----

Created an attachment (id=171136)
default.aspx




---- Additional Comments From grendello@gmail.com 2006-12-18 14:59:42 MST ----

The exception is thrown also with xsp1



---- Additional Comments From grendello@gmail.com 2006-12-19 07:42:41 MST ----

I should add this is happening on x86-64 (Ubuntu feisty)



---- Additional Comments From robertj@gmx.net 2006-12-25 21:25:16 MST ----

Created an attachment (id=171137)
host.cs




---- Additional Comments From robertj@gmx.net 2006-12-25 21:28:45 MST ----

I was not able to create another test case than hosting ASP.NET.

The test succeeds with `linears' turned off:

mcs /r:System.Web host.cs
mono --debug -O=-linears host.exe




---- Additional Comments From robertj@gmx.net 2006-12-30 18:54:12 MST ----

*** https://bugzilla.novell.com/show_bug.cgi?id=MONO80405 has been marked as a duplicate of this bug. ***



---- Additional Comments From grendello@gmail.com 2006-12-30 19:50:16 MST ----

Running under valgrind yields:

==24574== Thread 7:
==24574== Conditional jump or move depends on uninitialised value(s)
==24574==    at 0x4A0C06: mono_class_setup_vtable_general 
(class.c:2167)
==24574==    by 0x4A11E8: mono_class_setup_vtable (class.c:1832)
==24574==    by 0x479B23: mono_class_vtable (object.c:966)
==24574==    by 0x47C781: mono_object_new (object.c:2648)
==24574==    by 0x47D62F: mono_runtime_invoke_array (object.c:2564)
==24574==    by 0x48CD22: ves_icall_InternalInvoke (icall.c:2692)
==24574==    by 0x97C5255: ???
==24574==    by 0x97C4DA2: ???
==24574==    by 0x98D3919: ???
==24574==    by 0x98D2C53: ???
==24574== 
==24574== Invalid read of size 8
==24574==    at 0xA794098: ???
==24574==    by 0xA78B836: ???
==24574==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
Exception: System.NullReferenceException: Object reference not set to 
an instance of an object
  at ASP.default_aspx.CalledFrom () [0x00007] in /tmp/grendel-temp-
aspnet-0/498da95a/7332e9ff.0.cs:48 
==24574== 
==24574== Invalid read of size 8
==24574==    at 0xA79A581: ???
==24574==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==24574== 
==24574== ERROR SUMMARY: 77 errors from 3 contexts (suppressed: 49157 
from 3)
==24574== malloc/free: in use at exit: 12,094,622 bytes in 41,414 
blocks.
==24574== malloc/free: 425,576 allocs, 384,162 frees, 600,228,952 
bytes allocated.
==24574== For counts of detected errors, rerun with: -v
==24574== searching for pointers to 41,414 not-freed blocks.
==24574== checked 37,757,216 bytes.
==24574== 
==24574== LEAK SUMMARY:
==24574==    definitely lost: 181,144 bytes in 5,941 blocks.
==24574==      possibly lost: 3,072 bytes in 11 blocks.
==24574==    still reachable: 11,910,406 bytes in 35,462 blocks.
==24574==         suppressed: 0 bytes in 0 blocks.




---- Additional Comments From grendello@gmail.com 2007-01-04 18:15:45 MST ----

The main symptom of the linears breakage is that the thread local 
storage doesn't contain the frame information, but only in threads 
other than the thread where xsp is running. It might be a problem 
with one of the cpu registers related to the stack being overwritten.



---- Additional Comments From massi@ximian.com 2007-01-11 11:28:31 MST ----


While it is true that the bug does not show up with -O=-linears, it
is also true that it is not present in Mono 1.2, and the 1.2 JIT
produces *identical* code in the relevant method
"System.Web.Compilation.AspParser.GetServerTag"
(relevant because enabling-disabling linears on exactly that method
toggles the bug's presence).

So it can be that investigating -O=linears was not the right thing
to do.
On the other hand, backing out r69404 "fixes" this bug, while it
reintroduces https://bugzilla.novell.com/show_bug.cgi?id=MONO80235.

About the commented code enabled in r69404: Zoltan, in r61500, wrote
as a comment "This doesn't work because mono_class_from_mono_type ()
returns the original klass for a byref type, not a 'byref' class,
causing the JIT to create variables with the wrong type".
I also had big problems with this piece of code when trying to
implement type based alias analysis for HSSA.

Anyway, I'll investigate more.



---- Additional Comments From massi@ximian.com 2007-01-16 03:21:53 MST ----

As usual, in retrospect it was easy: mono_type_get_underlying_type
"strips" the byref information from the type.
I mean, a "System.Web.Compilation.TagType&" (note the final '&')
becomes a "System.Int32".
This makes so that, on 64 bit systems, mono_allocate_stack_slots_full
puts it in a 4 bytes available slot instead of an 8 bytes one: when
the variable is written it then overwrites (part of) the next slot.

This is easy to fix, but the question is: is this IMHO broken behavior
of mono_type_get_underlying_type intentional?
I mean, is there code relying on this?
If yes, I'll just fix mono_allocate_stack_slots_full, but I would
prefer fixing mono_type_get_underlying_type instead.



---- Additional Comments From massi@ximian.com 2007-01-16 04:24:12 MST ----

Created an attachment (id=171138)
Patch




---- Additional Comments From massi@ximian.com 2007-01-16 04:25:42 MST ----

This works here and causes no regressions: ok to commit?



---- Additional Comments From grendello@gmail.com 2007-01-16 04:57:06 MST ----

This fixes the issue for me too, thanks



---- Additional Comments From lupus@ximian.com 2007-01-16 06:28:04 MST ----

Just return the correct type instead of an intptr.



---- Additional Comments From massi@ximian.com 2007-01-17 18:04:01 MST ----

Fixed in svn (r71231).


Imported an attachment (id=171136)
Imported an attachment (id=171137)
Imported an attachment (id=171138)

Unknown operating system other. Setting to default OS "Other".