Option for not using SIGSTOP/SIGCONT because not all apps take it well

[podusowski]

This STOP/CONT pattern is used to avoid data-race between reading /proc and handling things like mmap events from the kernel, isn't it? Anyway, we are profiling some apps that don't take it very well since STOP causes syscalls to return abnormally. It should be fixed but you know, it is not always that easy. Therefore I'm proposing a switch to disable this behavior.

[koute]

Yes, the STOP/CONT are sent because the perf_event_open interface is somewhat broken and AFAIK it's not really possible to use it in a non-racy way with an application which is already running. (It really shows that it was designed mostly with the fork + exec model in mind where you always start a fresh instance when profiling.)

[koute]

Have you actually hit a genuine infinite loop here? AFAIK infinite loops shouldn't really be possible as you're going to overflow the stack sooner or later anyway.

Anyway, this change isn't really correct. Even though > 1000 frame deep stacks are certainly a sign of a problem they should still be gathered. I've seen such stack traces in the wild, and gathering as much of it as possible later helps to fix it if you can manage to get to the top. So what was your motivation in adding this here? If you want to limit stack traces to a certain length we could add an extra parameter instead.

[podusowski]

Yes, I've got it frequently in one of the cortex-15 app, but I cannot post it here nor dig into it further since I'm leaving the company.

What I managed to figure out though is that it looked like a arm unwinder bug, vec holding the frames kept allocating until it failed while trying to reallocate into 3.5 gigs.

[podusowski]

Hi, do you still want to make this as command line option? I'm asking because failed allocation, which is how this bug manifests itself, is just an abort, no panic nor Err. This makes it hard to diagnose if it happens to someone.