Created attachment 1059053 [details]
abrt report with the coredump

Asking logprint to parse the log on a still-mounted filesystem is fairly unusual, though we still shouldn't coredump.  I'm curious, what prompted you to point xfs_logprint at the mounted root filesystem?

-Eric

Note, the first thing logprint says is:

# xfs_logprint -c /dev/mapper/rhel-root
xfs_logprint: /dev/mapper/rhel-root contains a mounted and writable filesystem
...

I'm a little surprised we even proceed after that.

Created attachment 1059193 [details]
compressed copy of the log

xfs_logprint -c -f logfile seems to fail in the same way, for this copy of the log.

(In reply to Eric Sandeen from comment #3)
> Asking logprint to parse the log on a still-mounted filesystem is fairly
> unusual, though we still shouldn't coredump.  I'm curious, what prompted you
> to point xfs_logprint at the mounted root filesystem?
> 
> -Eric

sosreport :) See /usr/lib/python2.7/site-packages/sos/plugins/xfs.py, when enabling logprint option.

The easiest way of reproducing it via sosreport:

sosreport -o xfs -e xfs -a --batch -v
..
[plugin:xfs] collecting output of 'xfs_logprint -c /dev/mapper/rhel-root'
[plugin:xfs] collecting output of 'xfs_logprint -c /dev/vda1'
..

(-a means enabling all plugin options).


I don't know how often / meaningful / useful this option is, though.

Yeah, that's not a useful thing for sosreport to do.... Any idea why it was added?

So, while I'll look at logprint, I think this highlights a more important issue - we need to make the xfs plugin collect useful information.  Logprint is almost never going to be relevant, especially when the fs is mounted.  It's also going to produce potentially very large files.  I'd drop it from sos.

xfs-specific information which *would* be useful is things like:

* xfsprogs version (xfs_repair -V) (I suppose we have this already from rpm data?)
* xfs_info output for all filesystems
* xfs mount options (probably gathered already?)
* xfs_stats output /proc/fs/xfs/stat & /proc/fs/xfs/xqmstat

-Eric

(In reply to Eric Sandeen from comment #8)
> So, while I'll look at logprint, I think this highlights a more important
> issue - we need to make the xfs plugin collect useful information.  Logprint
> is almost never going to be relevant, especially when the fs is mounted. 
> It's also going to produce potentially very large files.  I'd drop it from
> sos.
> 
> xfs-specific information which *would* be useful is things like:
> 
> * xfsprogs version (xfs_repair -V) (I suppose we have this already from rpm
> data?)
> * xfs_info output for all filesystems
> * xfs mount options (probably gathered already?)
> * xfs_stats output /proc/fs/xfs/stat & /proc/fs/xfs/xqmstat
> 
> -Eric

Makes sense, I raised https://github.com/sosreport/sos/issues/621 and will propose a patch for sosreport, once the discussion there will settle down the desired final state. Thanks for input.

In logprint we do this, around line 754 of log_print.c:

            *ptr += be32_to_cpu(op_head->oh_len);
            if (op_head->oh_flags & XLOG_CONTINUE_TRANS)
                return 1;
            op_head = (xlog_op_header_t *)*ptr;

and in this case, oh_len seems invalid; with debugging:

op_head->oh_flags 0x0 oh_len 0x34000000

so we move the op_head pointer to invalid memory.  I'm not sure offhand what sanity testing we can put on that value in this case...

logprint is a semi-fragile debug-only tool.  We're more tolerant of failure, tbh, as it's not generally customer- or user-facing.  As such I'm closing this WONTFIX, and we should probably remove its use from sosreport.