[PATCH] runtime/unwind: Allow to increase MAX_CFI

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

[PATCH] runtime/unwind: Allow to increase MAX_CFI

Torsten Polle
Hi,

As discussed this patch allows to define the limit of CFIs to a higher value in case the limit is too low.

Kind Regards,
Torsten


0001-runtime-unwind-Allow-to-increase-MAX_CFI.patch (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] runtime/unwind: Allow to increase MAX_CFI

Mark Wielaard
Hi Torsten,

On Tue, Nov 27, 2018 at 10:37:08PM +0100, Torsten Polle wrote:
> As discussed this patch allows to define the limit of CFIs to a higher value in case the limit is too low.

Thanks, applied to git master.

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?

Cheers,

Mark
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] runtime/unwind: Allow to increase MAX_CFI

Torsten Polle
Hi Mark,

> Am 29.11.2018 um 19:06 schrieb Mark Wielaard <[hidden email]>:
>
> Hi Torsten,
>
> On Tue, Nov 27, 2018 at 10:37:08PM +0100, Torsten Polle wrote:
>> As discussed this patch allows to define the limit of CFIs to a higher value in case the limit is too low.
>
> Thanks, applied to git master.

Thanks.

> 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?

I’m working on it. But it’s not that trivial. I included tons of libraries with the '-d' option and have to identify the one(s) that is (are) causing the warnings.

> Cheers,
> Mark

Regards,
Torsten
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] runtime/unwind: Allow to increase MAX_CFI

Mark Wielaard
In reply to this post by Mark Wielaard
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 <[hidden email]>:
> > 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