[lttng-dev] Correctly using callstack-user context

Mathieu Desnoyers mathieu.desnoyers at efficios.com
Tue May 12 08:27:21 EDT 2020

----- On May 11, 2020, at 5:09 PM, lttng-dev <lttng-dev at lists.lttng.org> wrote: 

> Hi,
> As part of a big software safety certification effort, we are looking into
> making sure that some functions of our API do not allocate memory and do not
> use any blocking syscalls.

> This part is done and is working (using kmem_mm_page_{alloc,free} for memory
> allocations for now). However, if we do get memory allocations, we want to know
> where they're from. To do this, I've been looking at using the callstack-user
> context. However, I have a hard time getting more than 1 callstack-user
> address.

> I'm on 5.3.0-46-generic, i.e. CONFIG_ARCH_STACKWALK-compatible, from what I
> could find. I tried creating a minimal version using -fno-omit-frame-pointer &
> without any optimization, but I still get only one address in the
> callstack_user context when I know there should be at least a few.

> Note that this is running inside a Docker container, but lttng-modules is
> installed on the host, and a root session-daemon is running inside the Docker
> container. Also, I installed LTTng using the stable-2.11 Ubuntu PPA.

> Is there something I might be doing wrong? Am I supposed to compile
> lttng-modules from source in order to use the callstack-* contexts? I couldn't
> find much documentation about this, other than the brief mention in the 2.11
> docs.

How does your test program issue the system call ? Is it directly with syscall() (see syscall(2) man page), or 
does it call into libc ? Is your entire libc compiled with -fno-omit-frame-pointer ? 

As soon as one library in the chain to the system call is compiled without frame pointers, this is where the 
stack walk stops. This is usually libc. 



Mathieu Desnoyers 
EfficiOS Inc. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.lttng.org/pipermail/lttng-dev/attachments/20200512/b5228cbc/attachment.htm>

More information about the lttng-dev mailing list