Closed Bug 1756791 Opened 2 years ago Closed 2 years ago

The content process crashes when running with rr

Categories

(Core :: Gecko Profiler, defect, P5)

defect

Tracking

()

RESOLVED FIXED
100 Branch
Tracking Status
firefox-esr91 --- unaffected
firefox97 --- unaffected
firefox98 --- unaffected
firefox99 --- wontfix
firefox100 --- fixed

People

(Reporter: julienw, Assigned: julienw)

References

(Regression)

Details

(Keywords: regression)

Attachments

(1 file)

STR:

  1. run:
MOZ_PROFILER_STARTUP=1 MOZ_PROFILER_STARTUP_FEATURES=js,cpu,nostacksampling MOZ_PROFILER_SHUTDOWN=./profile.json ./mach run --debugger=rr --debugger-args="record --disable-avx-512 --disable-cpuid-features-ext 0xfc230000,0x2c42,0xc"

(you may need to adapt the arguments for your CPU)

  1. Notice that you can't load any website in Firefox.

In the console, I see:

Sandbox: seccomp sandbox violation: pid 246172, tid 246172, syscall 309, args 140736847751764 0 0 140736847751864 0 140736847751120.  Killing process.

With this diff, this works:

diff --git a/tools/profiler/core/platform.cpp b/tools/profiler/core/platform.cpp
index c54e94b64ff63..dffa052c49c14 100644
--- a/tools/profiler/core/platform.cpp
+++ b/tools/profiler/core/platform.cpp
@@ -6314,16 +6314,17 @@ void profiler_thread_sleep() {
   profiler_mark_thread_asleep();
   ThreadRegistration::WithOnThreadRef(
       [](ThreadRegistration::OnThreadRef aOnThreadRef) {
         aOnThreadRef.UnlockedConstReaderAndAtomicRWRef().SetSleeping();
       });
 }
 
 void profiler_mark_thread_awake() {
+  return;
   if (!profiler_thread_is_being_profiled_for_markers()) {
     return;
   }
 
   int64_t cpuId = 0;
 #if defined(GP_OS_windows)
   cpuId = GetCurrentProcessorNumber();
 #elif defined(GP_OS_darwin)

Then the issue may come from the syscall sched_getcpu():
https://searchfox.org/mozilla-central/rev/ad38c9d1f0a9036c4da5271a849f47342b68adc8/tools/profiler/core/platform.cpp#6340

Is it really a sandbox issue given this works fine when not using rr?

Keywords: regression
Regressed by: 1753305

What is the --disable-cpuid-features-ext parameter doing? Isn't it disabling the thing that sched_getcpu needs?

I think this is disabling some CPU features, that pernosco doesn't support.

Set release status flags based on info from the regressing bug 1753305

From :khuey: "The profiler is not compatible with rr's syscall buffering. Use rr record -n."
And I'm rarely running Linux, so I won't spend time on this. Patches welcome.

Severity: -- → S4
Priority: -- → P5
Has Regression Range: --- → yes

In the past before bug 1753305, this was working properly, with nostacksampling. It would be a shame that we can't use rr anymore because this tool helped us a lot in the past.

Recently bug 1753305 introduced the use of the getcpu syscall to add
this information to a profiler marker, but didn't allow this syscall
from the sandbox. For a yet-unexplained reason, the sandbox crashes the
process when starting the profiler but only when running under rr.

Thanks :padenot for all the help.

Assignee: nobody → felash
Status: NEW → ASSIGNED

(In reply to Julien Wajsberg [:julienw] from comment #6)

Created attachment 9265504 [details]
Bug 1756791 - Allow the getcpu syscall in the sandbox r=jld

Recently bug 1753305 introduced the use of the getcpu syscall to add
this information to a profiler marker, but didn't allow this syscall
from the sandbox. For a yet-unexplained reason, the sandbox crashes the
process when starting the profiler but only when running under rr.

Thanks :padenot for all the help.

The current guess is that without rr the call goes through the vdso mechanism, and therefore isn't caught by the sandbox. Because rr disables the vdso mechanism, this always goes through the sandbox in that case.

Attachment #9265504 - Attachment description: Bug 1756791 - Allow the getcpu syscall in the sandbox r=jld → Bug 1756791 - Allow the getcpu syscall in the sandbox r=gcp
Pushed by jwajsberg@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/5c92b5b84d4f
Allow the getcpu syscall in the sandbox r=gcp
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → 100 Branch
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: