[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. 

Thanks, 

Mathieu 

-- 
Mathieu Desnoyers 
EfficiOS Inc. 
http://www.efficios.com 
-------------- 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