On Tue, Apr 17, 2018 at 02:23:51PM +0200, Carlos Maiolino wrote:
> Hi,
>
> recently while playing with a FS image, I've hit an assertion in xfs_db:
>
> xfs_db: print.c:164: print_flist_1: Assertion `fa->arg & 64' failed.
> Aborted (core dumped)
>
> The reason for this assert was that I tried to print a remote attr3 block, after
> having set the block pointer to a random, no attr3 location.
>
> I wonder if crashing xfs_db here is the right thing to do?
>
>
> I've written a small workaround for it as below:
>
>
> @@ -160,9 +160,10 @@ print_flist_1(
> (f->flags & FLD_ARRAY) != 0);
> if (neednl)
> dbprintf("\n");
> - } else {
> - ASSERT(fa->arg & FTARG_OKEMPTY);
> + } else if (fa->arg & FTARG_OKEMPTY) {
> dbprintf(_("(empty)\n"));
> + } else {
> + dbprintf(_("Invalid arg\n"));
"Unrecognized metadata\n" ?
The block space pointer that got us here wasn't necessarily invalid,
it's just that we don't recognize the block as matching whatever type is
selected in the io cursor.
> }
> }
> free_strvec(pfx);
>
>
> I wonder if something like this makes sense or not? I'm still familiarizing
> myself with xfs_db code, so I'm not sure if something as the small patch above
> is a valid fix for it or not, but I believe exiting xfs_db just because somebody
> tried to print a metadata block using a different type from the on-disk block
> being read doesn't look like the right thing to do.
Funny, I've had a debug patch squirreled away in my xfsprogs tree for
ages to teach those ASSERTs not to abort the binary (which then sprays
core files everywhere). This one has been particularly annoying, so...
Reviewed-by: Darrick J. Wong <darrick.wong@xxxxxxxxxx>
--D
>
> Comments?
>
> Cheers
>
> --
> Carlos
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
