[Mono-bugs] [Bug 647464] Debugger segfaults on ASP.Net MVC projects

[bugzilla_noreply at novell.com]

https://bugzilla.novell.com/show_bug.cgi?id=647464

https://bugzilla.novell.com/show_bug.cgi?id=647464#c3


--- Comment #3 from Justen Hyde <Justen.Hyde at gmail.com> 2010-10-28 15:18:24 UTC ---
This appears not to be limited to ASP.net, but will kill the soft debugger on
any type of project on some machines - see
http://ubuntuforums.org/showthread.php?t=1602295 for a discussion.

To summarise: On machines using the sse4.2 instruction set there seems to be an
issue with the use of the optimised strstr function in glibc which causes a
segfault whenever the mono soft debugger is used. A VMWare image run on a
machine without an sse4.2 capable processor will behave normally (i.e., no
segfault), but if transferred onto a machine with an sse4.2 capable processor
will segfault in the same way as the host would (i.e., will segfault during
debugging), which suggests that when this issue occurs it's not due to a
misconfigured system.

If glibc is built without the sse4.2 optimised version of strstr enabled (as
seems to be the case in OpenSUSE), this issue is not apparent.

The mono code which calls through to strstr and causes the problem is in mini.c
line 3158:

3153    /* for these array methods we currently register the same function
pointer
3154     * since it's a vararg function. But this means that
mono_find_jit_icall_by_addr ()
3155     * will return the incorrect one depending on the order they are
registered.
3156     * See tests/test-arr.cs
3157     */
3158        if (strstr (info->name, "ves_array_new_va_") == NULL && strstr
(info->name, "ves_array_element_address_") == NULL) {
3159        patch_info->type = MONO_PATCH_INFO_INTERNAL_METHOD;
3160        patch_info->data.name = info->name;
3161    }

Most of the time this code works perfectly happily. If code is hacked at this
point to skip this conditional entirely if info->name is either
"mono_thread_force_interruption_checkpoint" or "mono_object_new_specific" the
problem goes away. There is nothing unusual about these strings; strstr handles
this strings out of the context of this problem without any trouble.

Inside strstr, the segfault traces to line 286 in x86_64/multiarch/strstr.c
inside glibc:

280  /* p1 > 1 byte long.  Load up to 16 bytes of fragment.  */
281  __m128i frag1 = strloadu (p1);
282
283  __m128i frag2;
284  if (p2[1] != '\0')
285    /* p2 is > 1 byte long.  */
286    frag2 = strloadu (p2); 
287  else
288    frag2 = _mm_insert_epi8 (_mm_setzero_si128 (), LOADBYTE (p2[0]), 0);

Checking the disassembly at this point:

Program received signal SIGSEGV, Segmentation fault.
0x00007f85b165ee6b in __strstr_sse42 (s1=0x6d5280
"mono_create_corlib_exception_1", s2=0x6d3f05 "ves_array_new_va_") at
./sysdeps/x86_64/multiarch/strstr.c:286

..

(gdb) disassemble

..

   0x00007f85b165ee60 <+880>:   mov    %rbx,%rax
   0x00007f85b165ee63 <+883>:   jmpq   0x7f85b165eb22 <__strstr_sse42+50>
   0x00007f85b165ee68 <+888>:   mov    %r13,%rdi
=> 0x00007f85b165ee6b <+891>:   movdqa %xmm0,(%rsp)
   0x00007f85b165ee70 <+896>:   callq  0x7f85b165e9b0 <__m128i_strloadu>
   0x00007f85b165ee75 <+901>:   movdqa %xmm0,0x10(%rsp)
   0x00007f85b165ee7b <+907>:   movdqa (%rsp),%xmm1
   0x00007f85b165ee80 <+912>:   jmpq   0x7f85b165eb98 <__strstr_sse42+168>

..

(gdb) p $rsp
$1 = (void *) 0x7fff829769e8

movdqa expects 16 byte alignment. %rsp isn't correctly aligned.

A similar problem to this has been reported on the NVidia Developer Zone forum
affecting the NVPerfKit tool (again a debugging tool as far as I can tell)
http://developer.nvidia.com/forums/index.php?showtopic=4926 

A very similar issue has also been reported on the glibc bug tracker:
http://sourceware.org/bugzilla/show_bug.cgi?id=12123

-- 
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.