Bug 323747 (MONO81063) - [ARM] Hit assertion in inssel-float.brg(CEE_STIND_R4) - remoting, ARM, vfp softfloat
Summary: [ARM] Hit assertion in inssel-float.brg(CEE_STIND_R4) - remoting, ARM, vfp so...
Status: RESOLVED FIXED
Alias: MONO81063
Product: Mono: Runtime
Classification: Mono
Component: JIT (show other bugs)
Version: 1.2
Hardware: Other Linux
: P3 - Medium : Blocker
Target Milestone: ---
Assignee: Rodrigo Kumpera
QA Contact: Mono Bugs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-03-07 01:28 UTC by Eric St-Onge
Modified: 2008-06-14 19:15 UTC (History)
2 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
Sample Code and log file (194.92 KB, application/octet-stream)
2007-03-07 01:29 UTC, Thomas Wiest
Details
Short test case exhibiting the problem (473 bytes, text/x-csharp)
2007-10-16 23:11 UTC, Henryk Plötz
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Wiest 2007-09-15 20:30:32 UTC


---- Reported by eric_st_onge@hotmail.com 2007-03-06 18:28:12 MST ----

Please fill in this template when reporting a bug, unless you know what 
you are doing.
Description of Problem:
Using 2007 Feb 06 HEAD SVN version. 
On a simple remoting case (client activated - no float involved), an 
assertion is hit in inssel.c:3502 -> inssel-float.brg(CEE_STIND_R4).

We have tried a fix, implementing the soft float version of CEE_STIND_R4, 
but since we dont master yet the tree structure of the JIT, we found it 
risky to submit this as a fix. 

Steps to reproduce the problem:
1. Compile the attached code
2. Execute the server - wait for confirmation
3. Execute the client
4. Assertion hit on the server.

Actual Results:
See attached zip file for complete log
mono_trace_bug_CEE_STIND_R4.txt

Expected Results:

How often does this happen? 
systematically using attached code.

Additional Information:

GLIB 2.12.9

gcc -v:
Reading specs from /home/eric//sdks//opt/toolchain-
3.3.1/devkit/arm/iwmmxt_le/bin/../lib/gcc-lib/armv5tel-hardhat-
linux/3.3.1/specs
Configured with: ../configure --host=i686-pc-linux-gnu --target=armv5tel-
hardhat-linux --prefix=/opt/montavista/cee/devkit/arm/iwmmxt_le --exec-
prefix=/opt/montavista/cee/devkit/arm/iwmmxt_le --
bindir=/opt/montavista/cee/devkit/arm/iwmmxt_le/bin --
sbindir=/opt/montavista/cee/devkit/arm/iwmmxt_le/sbin --
sysconfdir=/opt/montavista/cee/devkit/arm/iwmmxt_le/etc --
datadir=/opt/montavista/cee/devkit/arm/iwmmxt_le/share --
includedir=/opt/montavista/cee/devkit/arm/iwmmxt_le/include --
libdir=/opt/montavista/cee/devkit/arm/iwmmxt_le/lib --
libexecdir=/opt/montavista/cee/devkit/arm/iwmmxt_le/libexec --
localstatedir=/opt/montavista/cee/devkit/arm/iwmmxt_le/var --
sharedstatedir=/opt/montavista/cee/devkit/arm/iwmmxt_le/share --
mandir=/opt/montavista/cee/devkit/arm/iwmmxt_le/man --
infodir=/opt/montavista/cee/devkit/arm/iwmmxt_le/info --program-transform-
name=s,^,iwmmxt_le-, --enable-cross --with-
sysroot=/opt/montavista/cee/devkit/arm/iwmmxt_le/target --enable-shared --
enable-languages=c,c++ --enable-__cxa_atexit --enable-threads=posix --
disable-multilib --with-gxx-include-
dir='$'{gcc_tooldir}/../target/usr/include/c++/3.3.1 --with-float=soft --
with-cpu=iwmmxt --with-arch=iwmmxt --with-tune=iwmmxt --with-fpu=vfp
Thread model: posix
gcc version 3.3.1 (MontaVista 3.3.1-7.0.23.custom 2005-05-17)



---- Additional Comments From eric_st_onge@hotmail.com 2007-03-06 18:29:56 MST ----

Created an attachment (id=171615)
Sample Code and log file


Imported an attachment (id=171615)

Unknown bug field "cf_op_sys_details" encountered while moving bug
   <cf_op_sys_details>MontaVista Linux Consumer Electronics Edition 3.1Linux armv5tel 2.4.20 mvlcee31-mainstone pxa27x</cf_op_sys_details>

Comment 1 Henryk Plötz 2007-10-16 23:11:15 UTC
Created attachment 178883 [details]
Short test case exhibiting the problem
Comment 2 Rodrigo Kumpera 2007-11-06 14:03:14 UTC
The soft-float problem is gone on svn head, but now the client hits the following exception which doesn't happen on x86:

Unhandled Exception: System.NullReferenceException: Object reference not set to an instance of an object

Server stack trace: 
  at System.Runtime.Remoting.Messaging.MethodResponse..ctor (System.Exception e, IMethodCallMessage msg) [0x00000] 
  at System.Runtime.Remoting.Messaging.ConstructionResponse..ctor (System.Exception e, IMethodCallMessage msg) [0x00000] 
  at System.Runtime.Remoting.Activation.AppDomainLevelActivator.Activate (IConstructionCallMessage ctorCall) [0x00000] 
  at System.Runtime.Remoting.Activation.ActivationServices.RemoteActivate (IConstructionCallMessage ctorCall) [0x00000] 

Exception rethrown at [0]: 

  at System.Runtime.Remoting.Messaging.MethodResponse..ctor (System.Exception e, IMethodCallMessage msg) [0x00000] 
  at System.Runtime.Remoting.Messaging.ConstructionResponse..ctor (System.Exception e, IMethodCallMessage msg) [0x00000] 
  at System.Runtime.Remoting.Activation.AppDomainLevelActivator.Activate (IConstructionCallMessage ctorCall) [0x00000] 
  at System.Runtime.Remoting.Activation.ActivationServices.RemoteActivate (IConstructionCallMessage ctorCall) [0x00000] 

Comment 3 Rodrigo Kumpera 2007-12-11 13:46:51 UTC
This previous bug is fixed in r91089.

The bug still not fixed as there is one more issue left.

In the remoting server, a NRE is generated in ObjectReader::RecordFixup when is checks the length of the "indices" array.
Comment 4 Forgotten User vxPDddArjq 2008-06-14 19:15:06 UTC
This works fine with current SVN.