public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
From: Mark Wielaard <mark@klomp.org>
To: Torsten Polle <Torsten.Polle@gmx.de>
Cc: systemtap@sourceware.org
Subject: Re: [PATCH] runtime/unwind: Allow to increase MAX_CFI
Date: Fri, 30 Nov 2018 22:47:00 -0000	[thread overview]
Message-ID: <20181130224703.GP31795@wildebeest.org> (raw)
In-Reply-To: <FCB2E3ED-C261-46D0-AB9C-76EA3AA20083@gmx.de>

Hi Torsten,
[Sorry for the duplicate, I said I would CC the list, then forgot...]

On Fri, Nov 30, 2018 at 10:31:11PM +0100, Torsten Polle wrote:
> > Am 29.11.2018 um 19:06 schrieb Mark Wielaard <mark@klomp.org>:
> > I am still curious what program/library defines more than 512 CFI
> > instructions. If you could post some example of eu-readelf --debug-dump=frame
> > that would be interesting. I assume it must be some really big
> > functions that haven't been split up?
> 
> PFA the dump. As it is even compressed more than 2 MB, I just send it to you and not to the mailing list.

Wow, I had no idea. That is indeed huge. I inspected it and include the
mailinglist again so there is a bit of a record.

> This is the output of unwind.c with slightly modified messages.
> 
> unwind_frame:1291: processCFI for CIE: /usr/lib/libgtk-3.so.0.2000.9
> unwind_frame:1299: processCFI for FDE
> processCFI:312: Too many CFI instuctions: 5547
> 
> This is the first part backtrace.
> 0x4a8aa:libglib-2.0.so.0.4800.2:0xca2c:libgobject-2.0.so.0.4800.2:0xdf68:libgobject-2.0.so.0.4800.2:0x230c9:libgobject-2.0.so.0.4800.2:0x359d25:libgtk-3.so.0.2000.9

So 5547 is more than a factor 10 bigger than the current 512 limit.
Looking through the dump I see this must be either gtk_widget_class_init
or gtk_settings_class_intern_init. Both have a really big CFI descriptions.

I see the same in my local /usr/lib64/libgtk-3.so.0.2400.1 library.
Both functions seem to be just very long initialization sequnces.

Maybe we should increase the MAX_CFI by default.
But processing so many CFI instructions is resource intensive.
Maybe we should have a better way to just skip frames with
such complicated CFI.

Thanks,

Mark


      parent reply	other threads:[~2018-11-30 22:47 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-27 21:37 Torsten Polle
2018-11-29 18:06 ` Mark Wielaard
2018-11-29 21:12   ` Torsten Polle
     [not found]   ` <FCB2E3ED-C261-46D0-AB9C-76EA3AA20083@gmx.de>
2018-11-30 22:47     ` Mark Wielaard [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20181130224703.GP31795@wildebeest.org \
    --to=mark@klomp.org \
    --cc=Torsten.Polle@gmx.de \
    --cc=systemtap@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).