RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 592016 - Invalid C++ types resolution
Summary: Invalid C++ types resolution
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: gdb
Version: 6.0
Hardware: All
OS: Linux
low
low
Target Milestone: rc
: ---
Assignee: Jan Kratochvil
QA Contact: Petr Muller
URL:
Whiteboard: abrt_hash:f833c7548c5da5e598283cbcbce...
Depends On: 575292 585445
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-05-13 17:22 UTC by Jan Kratochvil
Modified: 2016-09-20 02:06 UTC (History)
5 users (show)

Fixed In Version: gdb-7.1-21.el6
Doc Type: Bug Fix
Doc Text:
Clone Of: 575292
Environment:
Last Closed: 2010-11-10 20:26:07 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
Proposed gdb-bz575292-delayed-physname.patch. (19.71 KB, patch)
2010-05-13 17:22 UTC, Jan Kratochvil 		no flags Details | Diff
View All

Description Jan Kratochvil 2010-05-13 17:22:47 UTC 
Created attachment 413827 [details]
Proposed gdb-bz575292-delayed-physname.patch.

+++ This bug was initially created as a clone of Bug #575292 + Bug #585445 +++

Bug #575292 was about a crash on reading webkit debuginfo.

How to reproduce
-----
1. Run an epiphany with custom-compiled libraries
2. Wait until it crashes
3. Start abrt
4. Click on "report"
5. Wait a bit
6. *boom*

This problem was fixed by delayed-physname patch by Keith Seitz but it caused an internal error - Bug #585445.  This second problem is now going to be fixed upstream http://sourceware.org/ml/gdb-patches/2010-05/msg00271.html .

But for RHEL-6.0 was chosen a safer way and the delayed-physname patch was adjusted by http://people.redhat.com/jkratoch/safer.patch which no longer has the risk of Bug #585445.

In the meantime in Bug 575292 Comment 13 I put there a workaround gdb-bz575292-void-workaround.patch and removed delayed-physname patch.  Such way it does not crash but on some C++ complicated data structures it prints invalid types for method parameters and it fails to lookup their function bodies.  This is the current state of RHEL-6.0, therefore gdb-7.1-19.el6 (and older builds).


Proposing a fix based on
        Re: [RFA] Delayed physname computation
        http://sourceware.org/ml/gdb-patches/2010-05/msg00248.html
patched by
        http://people.redhat.com/jkratoch/safer.patch
as attached herein.
Patch gdb-bz575292-void-workaround.patch can stay in place, it has no effect if the GDB would not crash otherwise.
Comment 1 RHEL Program Management 2010-05-13 17:47:13 UTC 
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.
Comment 2 Jan Kratochvil 2010-05-13 17:47:50 UTC 
There is new testcase:
pr11465.exp

One can also test no crashes on loading .debug files with -readnow such as:
webkitgtk-debuginfo-1.1.22-1.fc13.x86_64
gdb -nx -readnow /usr/lib/debug/usr/lib64/libwebkit-1.0.so.2.16.0.debug
Comment 7 Petr Muller 2010-10-01 16:03:15 UTC 
I also tried the second testcase. I tried both the suggested webkitgtk-debuginfo from fedora 13 (webkitgtk-debuginfo-1.1.22-1.fc13.x86_64) and current rh6 webkitgtk-debuginfo (webkitgtk-debuginfo-1.2.3-1.el6).

Both old and new gdb behave in the same way, no real crashes occured. However, there seem to be some memory issues. On s390x (which has 500MB of memory) the gdb gets (probably OOM-)Killed, and on i686 (which has the 3GB per-process memory limit afaik) it gets: 
Reading symbols from /tmp/debug/usr/lib/debug/usr/lib64/libwebkit-1.0.so.2.16.0.debug...expanding to full symbols...../../gdb/utils.c:1251: internal-error: virtual memory exhausted: can't allocate 4072 bytes.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n)

On other architectures, the gdb process has memory consumption peak ~3.5GB = 3632896 bytes (x86_64) and almost 5GB = 4922752 (ppc64), which was not problematic because the boxes were pretty beefy. Is this memory consumption consumption expected?
Comment 10 releng-rhel@redhat.com 2010-11-10 20:26:07 UTC 
Red Hat Enterprise Linux 6.0 is now available and should resolve
the problem described in this bug report. This report is therefore being closed
with a resolution of CURRENTRELEASE. You may reopen this bug report if the
solution does not work for you.
Note You need to log in before you can comment on or make changes to this bug.