This is Xamarin's bug tracking system. For product support, please use the support links listed in your Xamarin Account.
Bug 44164 - gosharp-regexp benchmark triggers unwinding crash when profiling
Summary: gosharp-regexp benchmark triggers unwinding crash when profiling
Status: RESOLVED FIXED
Alias: None
Product: Runtime
Classification: Mono
Component: JIT (show other bugs)
Version: Trunk
Hardware: PC Linux
: Normal normal
Target Milestone: Future Cycle (TBD)
Assignee: Zoltan Varga
URL:
Depends on:
Blocks:
 
Reported: 2016-09-10 06:24 UTC by Alex Rønne Petersen
Modified: 2016-09-13 22:42 UTC (History)
2 users (show)

See Also:
Tags:
Is this bug a regression?: ---
Last known good build:


Attachments

Description Alex Rønne Petersen 2016-09-10 06:24:42 UTC
To reproduce, clone Mono master, and do:

> $ make
> $ cd acceptance-tests
> $ make validate-benchmarker RESET_VERSIONS=1
> $ cd external/benchmarker/tests/gosharp
> $ ../../../../../runtime/mono-wrapper --profile=log:sample=cycles/480,sampling-real,maxsamples=5730,heapshot=10gc,maxframes=27,noalloc,output=/dev/null RegexpMatchHard_1K.exe

You will usually see a crash like this:

> BenchmarkRegexpMatchHard_1K: a Go test from regexp_test.go compiled into CIL. (iteration count N: 1024)
> Stacktrace:
> 
> * Assertion at mini-exceptions.c:955, condition `unwind_options == MONO_UNWIND_NONE' not met
> 
> [1]    31251 abort      mono  RegexpMatchHard_1K.exe

Curiously, if you run it with GDB, you'll instead see:

> BenchmarkRegexpMatchHard_1K: a Go test from regexp_test.go compiled into CIL. (iteration count N: 1024)
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x000000000052e54d in mono_unwind_frame (unwind_info=0x7fffebc50b55 "\f\a\b\220\001A\016\020\206\002C\r\006H\215\005D\216\004D\217\003\034\nD\b\rD\b\016D\b\017A\b\006\f\a\bA\v/\f\a\b\220\001A\016\020\206\002C\r\006H\214\006D\215\005D\216\004D\217\003\034\nD\b\fD\b\rD\b\016D\b\017A\b\006\f\a\bA\v)\f\a\b\220\001A\016\020\206\002C\r\006K\215\005D\216\004D\217\003\034\nD\b\rD\b\016D\b\017A\b\006\f\a\bA\v)\f\a\b\220\001A\016\020\206\002C\r\006H\214\005D\215\004D\216\003\034\nD\b\fD\b\rD\b\016A\b\006\f\a\bA\v#\f\a\b\220\001A\016\020\206\002C\r\006H\216\004D\217\003\034\nD\b\016D\b"..., unwind_info_len=41, start_ip=0x7fffeb526d50 "UH\213\354H\203\354@L\211m\350L\211u\360L\211}\370H\211}\330L\213\356L\213\362L\213\371M\205\355t\tM\205\366\017\205\071", end_ip=0x7fffeb526ed5 "ff.\017\037\204", ip=0x7fffeb526e4a "\377\351F", mark_locations=0x7fffffffaa00, regs=0x7fffffffa970, nregs=17, save_locations=0x0, save_locations_len=16, out_cfa=0x7fffffffa9f8) at unwind.c:625
> 625                                     regs [hreg] = *(mgreg_t*)(cfa_val + locations [i].offset);


This reproduces fairly reliably on Linux amd64. Not sure about other platforms.
Comment 1 Zoltan Varga 2016-09-13 13:04:23 UTC
The second issue should be fixed by 2ffa920376f3084884f5bec556dd3429d153271a.
Comment 2 Alex Rønne Petersen 2016-09-13 22:42:03 UTC
Both issues appear to have been fixed by that commit, so marking as resolved.

Note You need to log in before you can comment on or make changes to this bug.