Bug 1292556 - Userspace core support for interactive mode - using existing mock implementation
Userspace core support for interactive mode - using existing mock implementation
Status: NEW
Product: Fedora EPEL
Classification: Fedora
Component: retrace-server (Show other bugs)
Unspecified Unspecified
high Severity medium
: ---
: ---
Assigned To: Michal Toman
Fedora Extras Quality Assurance
Depends On: 1264005 1320104
  Show dependency treegraph
Reported: 2015-12-17 13:57 EST by Dave Wysochanski
Modified: 2016-11-30 19:52 EST (History)
12 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Dave Wysochanski 2015-12-17 13:57:41 EST
Description of problem:
There seems to be code for this but this has never worked as far as I know.  Some people have been working on this, and I think at least POC is worked out, but I'm not sure the limitations or the constraints.  For example, will cores from only certain RHELs be supported?  Also do we need to run retrace-server on RHEL7 or will our existing retrace-server on RHEL6 be ok?  Is there some setup required?

Version-Release number of selected component (if applicable):

How reproducible:
Every time.

Steps to Reproduce:
Submit a userspace core through the same 'manager' page.

Actual results:
retrace-server does not recognize the type of file or setup the proper libraries and environment to run gdb.

Expected results:
Able to run gdb on the userspace cores with all libraries loaded.

Additional info:
There was some significant code which went upstream in 1.13 so it may already be fixed.  Filing this to make sure it works in the latest code, and what the limitations may be.

I think we may need rhel7 base for this retrace-server functionality but I'm not sure.  

Also last I looked the existing code uses mock.  As has been seen with vmcores, mock has it's limitations / weaknesses such as only one user opening the core and security concerns (and see other retrace-server bugs which mention mock). 

There was at least one person attempting to do userspace cores with containers.  If there's competing implementations we may need to fork another bug for container implementation, or use this bug if it's feasible in the shorter term.
Comment 2 Harshula Jayasuriya 2015-12-17 18:26:36 EST
IIRC, there are multiple people working to solve this problem. Could we please have a status update from each? Thanks!
Comment 3 Brad Hubbard 2015-12-17 19:04:19 EST
I committed to looking into this and I have had a look but need to go much deeper. I hope to get the time to do this soon and will report back in the new year.
Comment 5 Brad Hubbard 2015-12-17 21:27:17 EST
I suggest we focus on handling mainstream before we even consider corner cases. There will always be corner cases such a 3p libs that we will not be able to get anything meningful from however we may be able to flag the presence of 3p libs due to unresolved or missing build-ids. Crawl before walk, walk before run.
Comment 9 Dave Wysochanski 2016-03-24 08:14:34 EDT
I would consider this another potential blocker, at least a 'nice to have':

Today userspace cores require 'reposync' and a copy of all packages on all distro versions where a core can come in.  This is really a huge overhead which seems unnecessary so it would be good if we can just use repos of all packages instead of copies.  The above bug is necessary since today we can only use a single repo AFAIK.

Note You need to log in before you can comment on or make changes to this bug.