ioctl(PERF_EVENT_IOC_SET_BPF): Bad file descriptor #2981
Replies: 3 comments 1 reply
-
I can repro your issue locally, but can't explain why there would be a difference between v0.19.1 and v0.20.1. The error message bpftrace is giving here is awful, sorry, but the issue seems to be that the loops in your script are simply too big for BPF. If you rerun with
The 1 million instruction limit is hardcoded into the kernel. Bpftrace does run your script, but bear in mind that the probes which are triggering this warning are not being run - only the others with no warnings. We're planning to provide better looping support in the future: #2807 |
Beta Was this translation helpful? Give feedback.
-
Thanks a lot for taking the time looking at my issue!
I really appreciate improvements to looping.
On the other hand: I currently need looping only to output longer
filenames.
Is there a way to do this without looping?
`printf "%s" str(filename, 200)` ... doesn't seem to work, just
the fist roughly 60ncharacters show up within the output file
Am 2024-02-05 16:24, schrieb Alastair Robertson:
I can repro your issue locally, but can't explain why there would be a
difference between v0.19.1 and v0.20.1.
The error message bpftrace is giving here is awful, sorry, but the
issue seems to be that the loops in your script are simply too big for
BPF. If you rerun with BPFTRACE_LOG_SIZE=10000000 bpftrace -v
myprog.bt, you'll probably see the message:
> BPF program is too large. Processed 1000001 insn
> processed 1000001 insns (limit 1000000) max_states_per_insn 23
> total_states 14642 peak_states 3706 mark_read 102
The 1 million instruction limit is hardcoded into the kernel.
Bpftrace does run your script, but bear in mind that the probes which
are triggering this warning are not being run - only the others with no
warnings.
We're planning to provide better looping support in the future: #2807
[1]
--
Reply to this email directly, view it on GitHub [2], or unsubscribe
[3].
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
Thanks again for taking the time looking at my issue.
Combining the two loops into one it what I had initially.
The code was quite similar to your proposal. But I printed the
string character by character (60 -> 1) and increased the offset
by 1 for each pass of the loop.
Unfortunately, output line tend to get "mixed up" by doing it this
way. I have the impression that each call to "printf" works atomically,
but multiple calls may be intermixed with those of different
processes/threads.
That's why I started to print blocks of 60 characters -> less calls of
printf
and less mixing up.
I'll do some more testing and hopefully, it will work out somehow.
Thanks a lot, I really appreciate your help and work! Best regards, Uli
Am 2024-02-06 10:59, schrieb Alastair Robertson:
> I currently need looping only to output longer filenames. Is there a
> way to do this without looping?
I managed to modify your script so that it doesn't give me the warnings
any more - you'll have to confirm that it still does the right thing
though :)
I combined your two loops (calculate strlen, print char-by-char) into
one:
$offset = 0;
while ($offset < 500) {
if (str($st+$offset, 1) == "") { break; }
printf("%.60s", str($st+$offset, 60));
$offset += 60;
}
It saves a handful of instructions, so might be pushing us just below
the limit.
> printf "%s" str(filename, 200) ... doesn't seem to work, just the fist
> roughly 60ncharacters show up within the output file
The second argument to str() only works to limit the length of a
string, it can't raise it above the size of the max_strlen. However, as
you've discovered, max_strlen can only go so high before our programs
run out of stack space. There's also more work planning in this area
(#2853 [1]), but for now the only solution is to be very economical
with the number of strings which the compiler can detect as "live" at
any one point in time, so that it can optimise them to occupy the same
stack space.
--
Reply to this email directly, view it on GitHub [2], or unsubscribe
[3].
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
I'm new to bpftrace, so maybe this is a silly question. I tried to google it but didn't find a good answer.
My issue: I'm getting errors like these when starting bpftrace:
I realized the I get the error once the script is becoming too complex. So I'm keeping it relatively compact
and it works quite well.
Recently, I realized that a script running quite well under v0.19.1 produces the errors when using v0.20.1.
Any idea? The script attached below contains comments in German. I can translate them to English if it is benefitial.
trace-open-close-rename.zip
Beta Was this translation helpful? Give feedback.
All reactions