ERROR: Macro recursion limit reached

[yangxingwu]

run a simple bpftrace result in a strange error:

program.bt:7:6-9: ERROR: Macro recursion limit reached: FOO, "hello world"
    @ = FOO
        ~~~
program.bt:7:6-9: ERROR: syntax error, unexpected end of file
    @ = FOO
        ~~~

the program is as follows:

$ cat program.bt
#!/usr/bin/bpftrace

#include <foo.h>

BEGIN
{
        @ = FOO
}

END
{
        printf("%s from BEGIN.\n", @);
}

$ cat foo.h
#define FOO "hello world"

But if I change the definition in foo.h to #define FOO 1 (also change related part in program.bt), everything works as expected. So I got two questions:

1. what does @ mean? does @ means a anonymous global var?
2. why bpftrace report ERROR: Macro recursion limit reached if #define FOO "hello world"

[BurntBrunch]

Hmm, this does not reproduce on v0.16 or on master. Can you please include a bpftrace --info like the template suggested?

A couple of other notes:

1. This shouldn't work with angled brackets (<foo.h>), do you have a foo.h installed in a system path? I get this error for a local file with angled brackets:

sudo src/bpftrace -v -e '#include <foo.h>
BEGIN { @ = FOO; exit() } END { printf("%s\n", @) }'
definitions.h:2:10: error: 'foo.h' file not found with <angled> include; use "quotes" instead

2. I can't reproduce it either:

sudo src/bpftrace -e '#include "foo.h"
BEGIN { @ = FOO; exit() } END { printf("%s\n", @) }'
Attaching 2 probes...
hello world


@: hello world

what does @ mean? does @ means a anonymous global var?

You can think of it this way, yes. In practice, @foo means a map named foo, @ is a shortcut for an unnamed map (I guess you can think of its name as @). Underneath, @ = "hello world" will put that value under a default 0 key.

[fbs]

Probably fixed in #2304

[yangxingwu]

1. bpftrace --info

$ System
  OS: Linux 5.15.0-52-generic #58-Ubuntu SMP Thu Oct 13 08:03:55 UTC 2022
  Arch: x86_64

Build
  version: v0.14.0
  LLVM: 11.1.0
  ORC: v2
  foreach_sym: yes
  unsafe uprobe: no
  bfd: no
  bpf_attach_kfunc: yes
  bcc_usdt_addsem: yes
  bcc bpf_attach_uprobe refcount: yes
  bcc library path resolution: yes
  libbpf: yes
  libbpf btf dump: yes
  libbpf btf dump type decl: yes
  libdw (DWARF support): no

Kernel helpers
  probe_read: yes
  probe_read_str: yes
  probe_read_user: yes
  probe_read_user_str: yes
  probe_read_kernel: yes
  probe_read_kernel_str: yes
  get_current_cgroup_id: yes
  send_signal: yes
  override_return: yes
  get_boot_ns: yes
  dpath: yes

Kernel features
  Instruction limit: 1000000
  Loop support: yes
  btf (depends on Build:libbpf): yes
  map batch (depends on Build:libbpf): yes
  uprobe refcount (depends on Build:bcc bpf_attach_uprobe refcount): yes

Map types
  hash: yes
  percpu hash: yes
  array: yes
  percpu array: yes
  stack_trace: yes
  perf_event_array: yes

Probe types
  kprobe: yes
  tracepoint: yes
  perf_event: yes
  kfunc: yes
  iter:task: yes
  iter:task_file: yes

---

2. about foo.h

This shouldn't work with angled brackets (<foo.h>), do you have a foo.h installed in a system path? I get this error for a local file with angled brackets:

I got a file named foo.h in the same directory of program.bt, and it simply contains a macro definition (as follows). I run with bpftrace -I . program.bt

$ cat foo.h
#define FOO "hello world"

$ cat program.bt
#!/usr/bin/bpftrace

#include <foo.h>

BEGIN
{
        @ = FOO
}

END
{
        printf("%s from BEGIN.\n", @);
}

Everything works as expected if I define FOO as an integer (for example, #define FOO 1). But if I define FOO as a string (likely #define FOO "hello world"), bpftrace reports the error.

---

3. about @

thanks for you info. So @ is simply a unnamed or anonymous map, right?

[yangxingwu]

Probably fixed in #2304

I test with #define FOOLL "hi", and everything works well :)

as #2304 suggested, the fix in #1650 causes all macros whose value is longer than their name to error out

Seems this bug is fixed in #2304