[lttng-dev] lttng-dev Digest, Vol 117, Issue 3

Majid Rezazadeh majid3612 at gmail.com
Tue Jan 9 22:51:45 UTC 2018


Hi Geneviève,

Thank you for your response.

I had tried your solution before. Unfortunately, there is no difference
between preloading one or two other shared libraries with my test library.
I am not sure about the reason, maybe a conflict between lttng and firefox
in access to shared resource.

Majid



On Tue, Jan 9, 2018 at 4:26 PM, <lttng-dev-request at lists.lttng.org> wrote:

> Send lttng-dev mailing list submissions to
>         lttng-dev at lists.lttng.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
> or, via email, send a message with subject or body 'help' to
>         lttng-dev-request at lists.lttng.org
>
> You can reach the person managing the list at
>         lttng-dev-owner at lists.lttng.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of lttng-dev digest..."
>
>
> Today's Topics:
>
>    1. Re: LD_PRELOAD applications using lttng-ust-pthread
>       (Jonathan Rajotte-Julien)
>    2. Re: LD_PRELOAD applications using lttng-ust-pthread
>       (Jonathan Rajotte-Julien)
>    3. Re: LD_PRELOAD applications using lttng-ust-pthread
>       (Genevieve Bastien)
>    4. [PATCH lttng-modules 3/3] Fix: Update btrfs       instrumentation
>       for v4.15 (Michael Jeanson)
>    5. [PATCH lttng-modules 2/3] Update kvm instrumentation      for
>       debian kernel 4.9.65-3 (Michael Jeanson)
>    6. [PATCH lttng-modules 1/3] Fix: debian kernel version      parsing
>       (Michael Jeanson)
>    7. Re: [PATCH lttng-modules 3/3] Fix: Update btrfs
>       instrumentation for v4.15 (Mathieu Desnoyers)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 9 Jan 2018 10:43:51 -0500
> From: Jonathan Rajotte-Julien <jonathan.rajotte-julien at efficios.com>
> To: Majid Rezazadeh <majid3612 at gmail.com>
> Cc: lttng-dev at lists.lttng.org
> Subject: Re: [lttng-dev] LD_PRELOAD applications using
>         lttng-ust-pthread
> Message-ID: <20180109154351.GA17950 at joraj-alpa>
> Content-Type: text/plain; charset=us-ascii
>
> Hi,
>
> On Mon, Jan 08, 2018 at 10:35:39PM -0500, Majid Rezazadeh wrote:
> > Hi all
> >
> > I am using lttng-ust-libc-wrapper for instrumenting some calls to libc
> for
> > some applications like Firefox and Chrome, but I receive "Segmentation
> > fault (core dumped)". I compile lttng-ust-pthread.c (gcc -fPIC -shared
> -o
> > test.so lttng-ust-pthread.c -ldl) and then I use "LD_PRELOAD=test.so
> > firefox" but I receive segmentation fault (I have exported
> LD_LIBRARY_PATH
> > to the absolute path of test.so file). I found out that when I replace
>
> Could you give us more information regarding the coredump?
>
> "thread apply all bt" in gdb with the corefile loaded.
>
> Make sure to compile with debug symbol and rerun your test.
>
> > tracepoints with printf in lttng_ust_pthread.c, I receive no error. It
> > seems that hooking tracepoints in this wrapper makes some problems. Do
> you
> > have any idea in this regard?
> >
> > Thanks
> >
> > Majid
>
> > _______________________________________________
> > lttng-dev mailing list
> > lttng-dev at lists.lttng.org
> > https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
>
>
> --
> Jonathan Rajotte-Julien
> EfficiOS
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 9 Jan 2018 10:47:10 -0500
> From: Jonathan Rajotte-Julien <jonathan.rajotte-julien at efficios.com>
> To: Majid Rezazadeh <majid3612 at gmail.com>
> Cc: lttng-dev at lists.lttng.org
> Subject: Re: [lttng-dev] LD_PRELOAD applications using
>         lttng-ust-pthread
> Message-ID: <20180109154710.GB17950 at joraj-alpa>
> Content-Type: text/plain; charset=us-ascii
>
> On Tue, Jan 09, 2018 at 10:43:51AM -0500, Jonathan Rajotte-Julien wrote:
> > Hi,
> >
> > On Mon, Jan 08, 2018 at 10:35:39PM -0500, Majid Rezazadeh wrote:
> > > Hi all
> > >
> > > I am using lttng-ust-libc-wrapper for instrumenting some calls to libc
> for
> > > some applications like Firefox and Chrome, but I receive "Segmentation
> > > fault (core dumped)". I compile lttng-ust-pthread.c (gcc -fPIC
> -shared  -o
> > > test.so lttng-ust-pthread.c -ldl) and then I use "LD_PRELOAD=test.so
> > > firefox" but I receive segmentation fault (I have exported
> LD_LIBRARY_PATH
> > > to the absolute path of test.so file). I found out that when I replace
> >
> > Could you give us more information regarding the coredump?
> >
> > "thread apply all bt" in gdb with the corefile loaded.
> >
> > Make sure to compile with debug symbol and rerun your test.
>
> Forgot to mention that you should open a bug here:
>
> https://bugs.lttng.org/
>
> Make sure to read the bug reporting guidelines.
>
> Cheers!
>
> --
> Jonathan Rajotte-Julien
> EfficiOS
>
>
> ------------------------------
>
> Message: 3
> Date: Tue, 9 Jan 2018 10:34:18 -0500
> From: Genevieve Bastien <gbastien+lttng at versatic.net>
> To: lttng-dev at lists.lttng.org
> Subject: Re: [lttng-dev] LD_PRELOAD applications using
>         lttng-ust-pthread
> Message-ID: <bfd757ed-4b3e-1294-f476-34a2b373acac at versatic.net>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Majid,
>
>
> See the documentation here:
> http://lttng.org/docs/v2.10/#doc-using-lttng-ust-with-daemons and
> http://lttng.org/docs/v2.10/#doc-liblttng-ust-fd. Firefox requires at
> least one of those extra libraries to be preloaded, the one for fork I
> think.
>
>
> I recall trying to trace firefox with lttng-cyg-profile without much
> success. Without the liblttng-ust-fork.so preloaded, my tabs had
> segfaults. But when I tried with both libraries, it seemed there was a
> conflict between cyg-profile and the other preloaded libraries, I don't
> remember exactly what happened. Maybe you won't have this problem with
> lttng-ust-libc-wrapper.
>
>
> I hope this helps,
>
> Geneviève
>
>
> On 2018-01-08 10:35 PM, Majid Rezazadeh wrote:
> > Hi all
> >
> > I am using lttng-ust-libc-wrapper for instrumenting some calls to libc
> > for some applications like Firefox and Chrome, but I receive
> > "Segmentation fault (core dumped)". I compile lttng-ust-pthread.c (gcc
> > -fPIC -shared  -o test.so lttng-ust-pthread.c -ldl) and then I use
> > "LD_PRELOAD=test.so firefox" but I receive segmentation fault (I have
> > exported LD_LIBRARY_PATH to the absolute path of test.so file). I
> > found out that when I replace tracepoints with printf in
> > lttng_ust_pthread.c, I receive no error. It seems that hooking
> > tracepoints in this wrapper makes some problems. Do you have any idea
> > in this regard?
> >
> > Thanks
> >
> > Majid
> >
> >
> > _______________________________________________
> > lttng-dev mailing list
> > lttng-dev at lists.lttng.org
> > https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <https://lists.lttng.org/pipermail/lttng-dev/attachments/
> 20180109/3b570b98/attachment-0001.html>
>
> ------------------------------
>
> Message: 4
> Date: Tue,  9 Jan 2018 15:43:21 -0500
> From: Michael Jeanson <mjeanson at efficios.com>
> To: lttng-dev at lists.lttng.org
> Subject: [lttng-dev] [PATCH lttng-modules 3/3] Fix: Update btrfs
>         instrumentation for v4.15
> Message-ID: <1515530601-19259-3-git-send-email-mjeanson at efficios.com>
>
> See upstream commit:
>
>   commit d278850eff3053ef166cf64c16f798dfe36278a2
>   Author: Josef Bacik <josef at toxicpanda.com>
>   Date:   Fri Sep 29 15:43:57 2017 -0400
>
>     btrfs: remove delayed_ref_node from ref_head
>
>     This is just excessive information in the ref_head, and makes the code
>     complicated.  It is a relic from when we had the heads and the refs in
>     the same tree, which is no longer the case.  With this removal I've
>     cleaned up a bunch of the cruft around this old assumption as well.
>
> Signed-off-by: Michael Jeanson <mjeanson at efficios.com>
> ---
>  instrumentation/events/lttng-module/btrfs.h | 18 +++++++++++++++++-
>  1 file changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/instrumentation/events/lttng-module/btrfs.h
> b/instrumentation/events/lttng-module/btrfs.h
> index b529e8e..7901f05 100644
> --- a/instrumentation/events/lttng-module/btrfs.h
> +++ b/instrumentation/events/lttng-module/btrfs.h
> @@ -680,7 +680,23 @@ LTTNG_TRACEPOINT_EVENT(btrfs_delayed_data_ref,
>         )
>  )
>
> -#if (LINUX_VERSION_CODE >= KERNEL_VERSION(4,8,0))
> +#if (LINUX_VERSION_CODE >= KERNEL_VERSION(4,15,0))
> +LTTNG_TRACEPOINT_EVENT(btrfs_delayed_ref_head,
> +
> +       TP_PROTO(struct btrfs_fs_info *fs_info,
> +                struct btrfs_delayed_ref_head *head_ref,
> +                int action),
> +
> +       TP_ARGS(fs_info, head_ref, action),
> +
> +       TP_FIELDS(
> +               ctf_integer(u64, bytenr, head_ref->bytenr)
> +               ctf_integer(u64, num_bytes, head_ref->num_bytes)
> +               ctf_integer(int, action, action)
> +               ctf_integer(int, is_data, head_ref->is_data)
> +       )
> +)
> +#elif (LINUX_VERSION_CODE >= KERNEL_VERSION(4,8,0))
>  LTTNG_TRACEPOINT_EVENT(btrfs_delayed_ref_head,
>
>         TP_PROTO(struct btrfs_fs_info *fs_info,
> --
> 2.7.4
>
>
>
> ------------------------------
>
> Message: 5
> Date: Tue,  9 Jan 2018 15:43:20 -0500
> From: Michael Jeanson <mjeanson at efficios.com>
> To: lttng-dev at lists.lttng.org
> Subject: [lttng-dev] [PATCH lttng-modules 2/3] Update kvm
>         instrumentation for debian kernel 4.9.65-3
> Message-ID: <1515530601-19259-2-git-send-email-mjeanson at efficios.com>
>
> Signed-off-by: Michael Jeanson <mjeanson at efficios.com>
> ---
>  instrumentation/events/lttng-module/kvm.h | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/instrumentation/events/lttng-module/kvm.h
> b/instrumentation/events/lttng-module/kvm.h
> index ea63e88..d9d0300 100644
> --- a/instrumentation/events/lttng-module/kvm.h
> +++ b/instrumentation/events/lttng-module/kvm.h
> @@ -86,7 +86,8 @@ LTTNG_TRACEPOINT_EVENT(kvm_ack_irq,
>
>  #if (LINUX_VERSION_CODE >= KERNEL_VERSION(4,15,0) \
>         || LTTNG_KERNEL_RANGE(3,16,52, 3,17,0) \
> -       || LTTNG_KERNEL_RANGE(3,2,97, 3,3,0))
> +       || LTTNG_KERNEL_RANGE(3,2,97, 3,3,0) \
> +       || LTTNG_DEBIAN_KERNEL_RANGE(4,9,65,0,3,0, 4,10,0,0,0,0))
>
>  LTTNG_TRACEPOINT_EVENT(kvm_mmio,
>         TP_PROTO(int type, int len, u64 gpa, void *val),
> --
> 2.7.4
>
>
>
> ------------------------------
>
> Message: 6
> Date: Tue,  9 Jan 2018 15:43:19 -0500
> From: Michael Jeanson <mjeanson at efficios.com>
> To: lttng-dev at lists.lttng.org
> Subject: [lttng-dev] [PATCH lttng-modules 1/3] Fix: debian kernel
>         version parsing
> Message-ID: <1515530601-19259-1-git-send-email-mjeanson at efficios.com>
>
> The debian version script only worked for ckt kernels and that was fine
> until now because we only had checks for those versions in the code.
>
> ckt (Canonical Kernel Team) kernels were used for a while during the jessie
> cycle, their versionning is a bit different. They track the upstream
> vanilla
> stable updates but they don't update the minor version number and instead
> add
> an additionnal -cktX. They were all 3.16.7-cktX and after a while the
> version
> switched back to upstream style at 3.16.36.
>
> Knowing that, we can compare regular debian and ckt kernel versions
> using this scheme :
>
>   MAJOR.PATCHLEVEL.SUBLEVEL.CKT.DEBABI.DEBPATCH
>
> And setting CKT to zero for non-ckt kernels.
>
> Signed-off-by: Michael Jeanson <mjeanson at efficios.com>
> ---
>  abi-debian-version.sh | 18 ++++++++++--------
>  1 file changed, 10 insertions(+), 8 deletions(-)
>
> diff --git a/abi-debian-version.sh b/abi-debian-version.sh
> index 310d6a8..36da212 100755
> --- a/abi-debian-version.sh
> +++ b/abi-debian-version.sh
> @@ -12,24 +12,26 @@ fi
>
>  # Assuming KPATH is the target kernel headers directory
>  DEB_PACKAGE_VERSION=$(sed -rn 's/^#define LINUX_PACKAGE_ID " Debian
> (.*)"/\1/p' ${KPATH}/include/generated/package.h)
> +
>  # Ignore backports part
>  DEB_PACKAGE_VERSION=$(echo ${DEB_PACKAGE_VERSION} | sed -r
> 's/~(bpo|deb).*//')
> +
> +# ckt (Canonical Kernel Team) kernels were used for a while during the
> jessie
> +# cycle, their versionning is a bit different. They track the upstream
> vanilla
> +# stable updates but they don't update the minor version number and
> instead add
> +# an additionnal -cktX. They were all 3.16.7-cktX and after a while the
> version
> +# switched back to upstream style at 3.16.36.
> +
>  # Get -ckt update number, if present
>  KERNEL_CKT_UPDATE=$(echo ${DEB_PACKAGE_VERSION} | sed -rn
> 's/^[0-9]+\.[0-9]+\.[0-9]+-ckt([0-9]+).*/\1/p')
> -
> -# Only care about the rest if it is a -ckt kernel, making sure we do not
> -# clash with older Debian kernels (e.g. Debian 3.2.65-1+deb7u2).
> -if [ -z "${KERNEL_CKT_UPDATE}" ]; then
> -       echo 0
> -       exit 0
> -fi
> +test -n "${KERNEL_CKT_UPDATE}" || KERNEL_CKT_UPDATE=0
>
>  # Get package revision
>  DEB_PACKAGE_REVISION=$(echo ${DEB_PACKAGE_VERSION} | sed -r
> 's/.*-([^-]+)$/\1/')
>  # Get non-sec update number
>  DEB_PACKAGE_REVISION_BASE=$(echo ${DEB_PACKAGE_REVISION} | sed -r
> 's/^([0-9]+).*/\1/')
>  # Get security update number, if present
> -DEB_PACKAGE_REVISION_SECURITY=$(echo ${DEB_PACKAGE_REVISION} | sed -rn
> 's/.*\+(squeeze|deb[0-9])+u([0-9]+)$/\1/p')
> +DEB_PACKAGE_REVISION_SECURITY=$(echo ${DEB_PACKAGE_REVISION} | sed -rn
> 's/.*\+(squeeze|deb[0-9]+)+u([0-9]+)$/\2/p')
>  test -n "${DEB_PACKAGE_REVISION_SECURITY}" ||
> DEB_PACKAGE_REVISION_SECURITY=0
>  # Combine all update numbers into one
>  DEB_API_VERSION=$((KERNEL_CKT_UPDATE * 10000 + DEB_PACKAGE_REVISION_BASE
> * 100 + DEB_PACKAGE_REVISION_SECURITY))
> --
> 2.7.4
>
>
>
> ------------------------------
>
> Message: 7
> Date: Tue, 9 Jan 2018 21:29:55 +0000 (UTC)
> From: Mathieu Desnoyers <mathieu.desnoyers at efficios.com>
> To: Michael Jeanson <mjeanson at efficios.com>
> Cc: lttng-dev <lttng-dev at lists.lttng.org>
> Subject: Re: [lttng-dev] [PATCH lttng-modules 3/3] Fix: Update btrfs
>         instrumentation for v4.15
> Message-ID:
>         <2113123048.49851.1515533395136.JavaMail.zimbra at efficios.com>
> Content-Type: text/plain; charset=utf-8
>
> ----- On Jan 9, 2018, at 3:43 PM, Michael Jeanson mjeanson at efficios.com
> wrote:
>
> > See upstream commit:
> >
> >  commit d278850eff3053ef166cf64c16f798dfe36278a2
> >  Author: Josef Bacik <josef at toxicpanda.com>
> >  Date:   Fri Sep 29 15:43:57 2017 -0400
> >
> >    btrfs: remove delayed_ref_node from ref_head
> >
> >    This is just excessive information in the ref_head, and makes the code
> >    complicated.  It is a relic from when we had the heads and the refs in
> >    the same tree, which is no longer the case.  With this removal I've
> >    cleaned up a bunch of the cruft around this old assumption as well.
>
> In 3.12, this becomes a DECLARE_EVENT_CLASS with associated DEFINE_EVENT
> using the class. Example code snippet from a 4.15-rc kernel:
>
> DECLARE_EVENT_CLASS(btrfs_delayed_ref_head,
>
>         TP_PROTO(const struct btrfs_fs_info *fs_info,
>                  const struct btrfs_delayed_ref_head *head_ref,
>                  int action),
>
>         TP_ARGS(fs_info, head_ref, action),
>
>         TP_STRUCT__entry_btrfs(
>                 __field(        u64,  bytenr            )
>                 __field(        u64,  num_bytes         )
>                 __field(        int,  action            )
>                 __field(        int,  is_data           )
>         ),
>
>         TP_fast_assign_btrfs(fs_info,
>                 __entry->bytenr         = head_ref->bytenr;
>                 __entry->num_bytes      = head_ref->num_bytes;
>                 __entry->action         = action;
>                 __entry->is_data        = head_ref->is_data;
>         ),
>
>         TP_printk_btrfs("bytenr=%llu num_bytes=%llu action=%s is_data=%d",
>                   (unsigned long long)__entry->bytenr,
>                   (unsigned long long)__entry->num_bytes,
>                   show_ref_action(__entry->action),
>                   __entry->is_data)
> );
>
> DEFINE_EVENT(btrfs_delayed_ref_head,  add_delayed_ref_head,
>
>         TP_PROTO(const struct btrfs_fs_info *fs_info,
>                  const struct btrfs_delayed_ref_head *head_ref,
>                  int action),
>
>         TP_ARGS(fs_info, head_ref, action)
> );
>
> DEFINE_EVENT(btrfs_delayed_ref_head,  run_delayed_ref_head,
>
>         TP_PROTO(const struct btrfs_fs_info *fs_info,
>                  const struct btrfs_delayed_ref_head *head_ref,
>                  int action),
>
>         TP_ARGS(fs_info, head_ref, action)
> );
>
> It appears that this instrumentation has not been hooked on any actual
> tracepoint for quite some time in lttng-modules.
>
> We should adapt the lttng-modules instrumentation accordingly. I would
> not be surprised that the 4.8.0 kernel version range is also incorrect:
> it should apply to the "new" events based on the tracepoint class.
>
> Thanks,
>
> Mathieu
>
> >
> > Signed-off-by: Michael Jeanson <mjeanson at efficios.com>
> > ---
> > instrumentation/events/lttng-module/btrfs.h | 18 +++++++++++++++++-
> > 1 file changed, 17 insertions(+), 1 deletion(-)
> >
> > diff --git a/instrumentation/events/lttng-module/btrfs.h
> > b/instrumentation/events/lttng-module/btrfs.h
> > index b529e8e..7901f05 100644
> > --- a/instrumentation/events/lttng-module/btrfs.h
> > +++ b/instrumentation/events/lttng-module/btrfs.h
> > @@ -680,7 +680,23 @@ LTTNG_TRACEPOINT_EVENT(btrfs_delayed_data_ref,
> >       )
> > )
> >
> > -#if (LINUX_VERSION_CODE >= KERNEL_VERSION(4,8,0))
> > +#if (LINUX_VERSION_CODE >= KERNEL_VERSION(4,15,0))
> > +LTTNG_TRACEPOINT_EVENT(btrfs_delayed_ref_head,
> > +
> > +     TP_PROTO(struct btrfs_fs_info *fs_info,
> > +              struct btrfs_delayed_ref_head *head_ref,
> > +              int action),
> > +
> > +     TP_ARGS(fs_info, head_ref, action),
> > +
> > +     TP_FIELDS(
> > +             ctf_integer(u64, bytenr, head_ref->bytenr)
> > +             ctf_integer(u64, num_bytes, head_ref->num_bytes)
> > +             ctf_integer(int, action, action)
> > +             ctf_integer(int, is_data, head_ref->is_data)
> > +     )
> > +)
> > +#elif (LINUX_VERSION_CODE >= KERNEL_VERSION(4,8,0))
> > LTTNG_TRACEPOINT_EVENT(btrfs_delayed_ref_head,
> >
> >       TP_PROTO(struct btrfs_fs_info *fs_info,
> > --
> > 2.7.4
>
> --
> Mathieu Desnoyers
> EfficiOS Inc.
> http://www.efficios.com
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> lttng-dev mailing list
> lttng-dev at lists.lttng.org
> https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
>
>
> ------------------------------
>
> End of lttng-dev Digest, Vol 117, Issue 3
> *****************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.lttng.org/pipermail/lttng-dev/attachments/20180109/23d9b9a9/attachment-0001.html>


More information about the lttng-dev mailing list