Bug 212539 - readelf -w consumes a lot of memory with GCC-compiled kernels
Summary: readelf -w consumes a lot of memory with GCC-compiled kernels
Status: In Progress
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: CURRENT
Hardware: amd64 Any
: --- Affects Some People
Assignee: Ed Maste
URL:
Keywords:
Depends on:
Blocks: 231027
  Show dependency treegraph
 
Reported: 2016-09-09 22:52 UTC by Mark Johnston
Modified: 2019-04-23 17:24 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mark Johnston freebsd_committer 2016-09-09 22:52:18 UTC
I tried compiling a kernel with both gcc48 and gcc6 and hit the same problem with both. Running readelf -w against kernel.full causes it to emit a bunch of errors:

$ readelf -w kernel.full >/dev/null
readelf: dwarf_loclist_form_expr_b: Invalid location expression [_dwarf_loc_fill_locdesc(632)]
readelf: dwarf_loclist_form_expr_b: Invalid location expression [_dwarf_loc_fill_locdesc(632)]
readelf: dwarf_loclist_form_expr_b: Invalid location expression [_dwarf_loc_fill_locdesc(632)]
readelf: dwarf_loclist_form_expr_b: Invalid location expression [_dwarf_loc_fill_locdesc(632)]
readelf: dwarf_loclist_form_expr_b: Invalid location expression [_dwarf_loc_fill_locdesc(632)]
readelf: dwarf_loclist_form_expr_b: Invalid location expression [_dwarf_loc_fill_locdesc(632)]
readelf: dwarf_loclist_form_expr_b: Invalid location expression [_dwarf_loc_fill_locdesc(632)]

and it seemingly runs forever while consuming ever-increasing amounts of memory:

 2558 markj      103    0  3615M  3591M CPU0    0   2:07  97.33% readelf -w kernel.full
Comment 1 Ed Maste freebsd_committer 2018-08-01 14:41:56 UTC
Which readelf is this (GNU or ELF Tool Chain)?
Comment 2 Mark Johnston freebsd_committer 2018-08-01 15:46:02 UTC
It's elftoolchain.  The issue is still reproducible with at least gcc 6.
Comment 3 commit-hook freebsd_committer 2019-04-17 17:00:22 UTC
A commit references this bug:

Author: emaste
Date: Wed Apr 17 17:00:16 UTC 2019
New revision: 346323
URL: https://svnweb.freebsd.org/changeset/base/346323

Log:
  readelf: speed up readelf -wo

  Use an array instead of STAILQ, and sort at the end instead of while
  adding new elements.

  PR:		212539
  Submitted by:	Bora ?zarslan <borako.ozarslan@gmail.com>
  Reviewed by:	markj
  MFC after:	2 weeks
  Sponsored by:	The FreeBSD Foundation

Changes:
  head/contrib/elftoolchain/readelf/readelf.c
Comment 4 Conrad Meyer freebsd_committer 2019-04-17 17:22:38 UTC
(In reply to commit-hook from comment #3)
> Author: emaste
> Date: Wed Apr 17 17:00:16 UTC 2019
> New revision: 346323
> URL: https://svnweb.freebsd.org/changeset/base/346323

Would it makes sense to bump the size of la_list_cap and la_list_len to size_t?  4 billion is a lot of items, but sometimes we encounter it in other areas.  I don't know much about this particular tool so please excuse this comment if it is completely inappropriate.
Comment 5 Ed Maste freebsd_committer 2019-04-17 17:50:37 UTC
(In reply to Conrad Meyer from comment #4)

Even if no reasonable application is going to have that many elements, size_t is the proper type for this. Will update.
Comment 6 commit-hook freebsd_committer 2019-04-17 17:51:07 UTC
A commit references this bug:

Author: emaste
Date: Wed Apr 17 17:50:44 UTC 2019
New revision: 346327
URL: https://svnweb.freebsd.org/changeset/base/346327

Log:
  readelf: use size_t for object counts

  PR:		212539
  Reported by:	cem
  Sponsored by:	The FreeBSD Foundation

Changes:
  head/contrib/elftoolchain/readelf/readelf.c