[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