Bug 1201749 - 'coresize' field of stats sqlite database always NULL
Summary: 'coresize' field of stats sqlite database always NULL
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora EPEL
Classification: Fedora
Component: retrace-server
Version: epel7
Hardware: Unspecified
OS: Unspecified
unspecified
low
Target Milestone: ---
Assignee: Michal Toman
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-03-13 12:22 UTC by Dave Wysochanski
Modified: 2018-02-20 16:24 UTC (History)
3 users (show)

Fixed In Version: retrace-server-1.18.0-1.fc27 retrace-server-1.18.0-1.el7
Clone Of:
Environment:
Last Closed: 2018-02-13 17:52:11 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Dave Wysochanski 2015-03-13 12:22:42 UTC
Description of problem:

For some reason the 'coresize' field in the 'tasks' table is always NULL, which must be a bug.

$ sqlite3 /cores/retrace/tasks/stats.db
sqlite> .dump tasks
...

INSERT INTO "tasks" VALUES(7350,854078172,'kernel','2.6.32-220.17.1.el6','x86_64',1426209353,486,NULL,6);
INSERT INTO "tasks" VALUES(7351,480791831,'kernel','2.6.32-220.17.1.el6','x86_64',1426209424,468,NULL,6);
INSERT INTO "tasks" VALUES(7352,937645551,NULL,NULL,NULL,1426213076,601,NULL,7);
INSERT INTO "tasks" VALUES(7353,286770388,'kernel','2.6.18-371.12.1.el5','x86_64',1426227219,77,NULL,6);
INSERT INTO "tasks" VALUES(7354,939050538,'kernel','2.6.32-358.el6','x86_64',1426231351,2026,NULL,6);
INSERT INTO "tasks" VALUES(7355,791138625,'kernel','2.6.32-358.el6','x86_64',1426231396,2420,NULL,6);
INSERT INTO "tasks" VALUES(7356,951548981,'kernel','2.6.32-358.el6','x86_64',1426231428,3060,NULL,6);
INSERT INTO "tasks" VALUES(7357,174468018,'kernel','2.6.32-504.3.3.el6','x86_64',1426235617,110,NULL,6);
INSERT INTO "tasks" VALUES(7358,527768478,'kernel','2.6.32-431.20.3.el6','x86_64',1426247554,33,NULL,6);
CREATE TABLE success(taskid REFERENCES tasks(id), pre NOT NULL, post NOT NULL,
              rootsize NOT NULL);
CREATE TABLE packages(id INTEGER PRIMARY KEY AUTOINCREMENT,
               name NOT NULL, version NOT NULL);
CREATE TABLE packages_tasks(pkgid REFERENCES packages(id),
                     taskid REFERENCES tasks(id));
CREATE TABLE buildids(taskid REFERENCES tasks(id), soname, buildid NOT NULL);
CREATE TABLE reportfull(requesttime NOT NULL, ip NOT NULL);
DELETE FROM sqlite_sequence;
INSERT INTO "sqlite_sequence" VALUES('tasks',7358);
COMMIT;
sqlite> .schema tasks
CREATE TABLE tasks(id INTEGER PRIMARY KEY AUTOINCREMENT, taskid, package, version,
      arch, starttime NOT NULL, duration NOT NULL, coresize, status NOT NULL);



Version-Release number of selected component (if applicable):
retrace-server-1.12-3.el6.noarch


How reproducible:
Any retrace-server task has this problem.


Steps to Reproduce:
Dump out any record in the tasks table and look at 'coresize'

Actual results:
NULL coresize

Expected results:
Non-null coresize


Additional info:
I briefly looked at this but the error wasn't obvious.  Probably turn on some debugging and run it and the problem may be obvious.  At first I thought maybe the filename was just wrong - I didn't know the vmcore was named 'coredump' at one point.  However, this looks ok since we use it later to set the 'arch' and this is always set properly in the database, or so it seems.

See /usr/bin/retrace-server-worker and start_retrace() 

def start_retrace():
    crashdir = os.path.join(task.get_savedir(), "crash")
    corepath = os.path.join(crashdir, "coredump")  <------------------ is that right?

    try:
        stats["coresize"] = os.path.getsize(corepath)
    except:
        pass

   if cmdline.arch:
        log_debug("Using architecture from command line: %s" % cmdline.arch)
        arch = cmdline.arch
    else:
        # read architecture from coredump
        arch = guess_arch(corepath)

        if not arch:
            log_error("Unable to determine architecture from coredump")
            fail()

        log_debug("Determined architecture: %s" % arch)

    stats["arch"] = arch

Comment 1 Matej Marušák 2017-04-24 06:57:16 UTC
Fixed in https://github.com/abrt/retrace-server/commit/c9eac56

Comment 2 Fedora Update System 2018-02-01 15:52:19 UTC
retrace-server-1.18.0-1.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-e5741ca105

Comment 3 Fedora Update System 2018-02-01 15:52:43 UTC
retrace-server-1.18.0-1.el7 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-bc35ca9028

Comment 4 Fedora Update System 2018-02-02 18:24:46 UTC
retrace-server-1.18.0-1.el7 has been pushed to the Fedora EPEL 7 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-bc35ca9028

Comment 5 Fedora Update System 2018-02-02 18:48:01 UTC
retrace-server-1.18.0-1.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-e5741ca105

Comment 6 Fedora Update System 2018-02-13 17:52:11 UTC
retrace-server-1.18.0-1.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.

Comment 7 Fedora Update System 2018-02-20 16:24:09 UTC
retrace-server-1.18.0-1.el7 has been pushed to the Fedora EPEL 7 stable repository. If problems still persist, please make note of it in this bug report.


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