Skip to content
Snippets Groups Projects
  1. Nov 30, 2021
  2. Nov 19, 2021
  3. Nov 10, 2021
  4. Nov 03, 2021
  5. Oct 07, 2021
  6. Sep 30, 2021
  7. Sep 28, 2021
  8. Sep 27, 2021
    • Matt Ward's avatar
      [MacSDK] Add F# targets to VisualStudio/v17.0 directory (#21218) · 66e81934
      Matt Ward authored
      .NET 6 RC 2 adds an MSBuild check to see that the VisualStudioVersion
      property is below 17.0 and reports a not supported warning if this is
      the case. Updating the VisualStudioVersion to 17.0 used in Visual
      Studio for Mac 17.0 to fix this warning breaks F# SDK projects and
      classic F# projects since Mono's MSBuild tries to load F# targets
      files from a directory which does not exist:
      
         xbuild/Microsoft/VisualStudio/v17.0/FSharp
      
      Adding a v17.0 directory to Mono allows Visual Studio for Mac 17.0
      to define VisualStudioVersion to be 17.0 and restore and build F#
      projects.
      66e81934
  9. Sep 03, 2021
  10. Aug 30, 2021
  11. Aug 19, 2021
  12. Aug 13, 2021
  13. Jun 25, 2021
  14. Jun 24, 2021
    • Aleksey Kliger (λgeek)'s avatar
      [2020-02] Start a dedicated thread for MERP crash reporting (#21126) · 63035635
      Aleksey Kliger (λgeek) authored
      Related to #21009.
      
      There are two scenarios:
      1.  When someone force quits Mono (or just runs `kill -TERM <pid>`), the process can receive the signal on any thread,
      2. or - if a thread in the process crashes, but the thread is not attached to the runtime, Mono's signal handlers still run.
      
      The crash reporter assumes that the crashing thread is either attached to the runtime, or at least `mono_thread_info_current` or the JIT TLS data are set for the thread.  If the thread is truly foreign and it never interacted with Mono, and it crashes, both of those assumptions are false, but Mono's crash reporter signal handlers still run.
      
      The solution from this PR is: if crash reporting is enabled, start a dedicated thread at process startup that is a "crash report leader" - when a crash happens, the crashing thread (the crash originator) wakes the leader, and the leader collects the crash report.  The crash originator does not do any work that requires being attached to the runtime or to the JIT such as iterating over thread IDs or stack walking.
      
      
      ---
      
      * Add a standalone test of crash on a foreign thread
      
      * Sketch out crash leader implementation
      
         At process startup, start a separate thread that is attached to the runtime and can collect crash reports.  Crashing threads will wake it and wait for it to collect the crash reports
      
      * Start moving responsibilities to the crash leader
      
      * Watch for nil jit_tls data if crash is on a foreign thread
      
      * Start adding a state machine for the crash leader
      
         We need to coordinate the originator and the leader in a few places.
      
         The leader needs to pause to after collecting the thread ids before suspending the non-originator threads, and again while the originator is dumping its own stack.
      
         The originator needs to wait for the leader to collect the thread IDs and to tell it its assigned slot. Then it tells the leader to suspend the others, dumps its own memory, then tell the leader to dump the whole crash report and wait for it to reply when it's done.
      
      * Move remaining summarizer work to the summarizer leader thread
      
      * change some debug printfs
      
      * Successfully summarize a foreign thread crash
      
      * Add test to merp-crash-test.cs
      
      * delete standalone test
      
      * if the crash leader is the originator, collect the report synchronously
      
         either because the crash leader crashed, or because the process got a SIGTERM and it arrived on the crash leader thread
      
      * fixup comments
      
      * turn off crash leader printf debugging
      
      * Don't create leader thread if crash reporting is disabled
      
      * Fix test on win32
      
      * Update mono/tests/libtest.c
      
      * fixup logging and comments around managed stack collection
      
      * Disable the merp dlopen crasher
      
      * Remove crash leader state machine
      
         It's straightline code with two early exits. State machine is overkill
      
      * remove remnants of leader state machine
  15. May 27, 2021
  16. May 10, 2021
  17. Apr 30, 2021
  18. Apr 29, 2021
  19. Apr 19, 2021
  20. Apr 13, 2021
  21. Mar 30, 2021
  22. Mar 29, 2021
  23. Mar 27, 2021
  24. Mar 23, 2021
  25. Mar 11, 2021
  26. Mar 10, 2021
  27. Mar 09, 2021
  28. Mar 08, 2021
  29. Feb 22, 2021
  30. Feb 18, 2021
Loading