Hello Vance (and Chris),

I've tracked down the problem and it is indeed a JIT bug. 

Here's the a fragment of the IL code:

      IL_005f:  ldarg.2
      IL_0060:  ldc.i4.5
      IL_0061:  ldloc.0
      IL_0062:  ldc.i4.7
      IL_0063:  mul
      IL_0064:  add
      IL_0065:  ldelem.ref
      IL_0066:  brfalse    IL_0078
      IL_006b:  ldloc.1
      IL_006c:  ldarg.2
      IL_006d:  ldc.i4.5
      IL_006e:  ldloc.0
      IL_006f:  ldc.i4.7
      IL_0070:  mul
      IL_0071:  add
      IL_0072:  ldelem.ref
      IL_0073:  call       void com.ullink.mdif.adapter.glapifeed.data.GLData::updateLimitPrice(class com.ullink.mdif.toolkit.data.orderbook.BookLimit, string)

In non-optimizing mode, this gets compiled to:

00000111  imul        eax,esi,7 
00000114  add         eax,5 
00000117  cmp         eax,dword ptr [edi+4] 
0000011a  jb          00000121 
0000011c  call        75B18251 
00000121  cmp         dword ptr [edi+eax*4+0Ch],0 
00000126  je          00000146 
00000128  imul        eax,esi,7 
0000012b  add         eax,5 
0000012e  cmp         eax,dword ptr [edi+4] 
00000131  jb          00000138 
00000133  call        75B18251 
00000138  mov         edx,dword ptr [edi+eax*4+0Ch] 
0000013c  mov         ecx,dword ptr [esp+8] 
00000140  call        dword ptr ds:[04569720h] 

In optimizing mode however, the second ldelem.ref gets a completely bogus offset:

000000ce  imul        eax,esi,7 
000000d1  add         eax,5 
000000d4  cmp         eax,dword ptr [edi+4] 
000000d7  jae         000002DA 
000000dd  cmp         dword ptr [edi+eax*4+0Ch],0 
000000e2  je          000000F6 
000000e4  imul        eax,esi,7 
000000e7  mov         edx,dword ptr [edi+eax*4+00000098h] 
000000ee  mov         ecx,ebx 
000000f0  call        dword ptr ds:[015F8C18h] 

Note the +00000098h that doesn't make any sense.

I wonder if this also works for stelem.ref, because in that case it would be a nicely exploitable security hole!

Regards,
Jeroen