----- Original Message -----
> Hello,
>
> We recently encountered an issue where a transaction_t struct appeared
> to be corrupt but this ended up being a symbol conflict as the customer
> was using ext3 and ext4 and had both modules in use. Unloading the jbd
> module did not help and the only way to see the correct representation
> of the the transaction_t struct in question was to restart crash without
> any modules loaded and load only the jbd2 module.
That may be the best way to deal with it, however...
> Is this a known issue? Is there a strategy that needs to be followed for
> dealing with duplicate symbols?
Yes it is a known issue. You may be able to use "set scope <text-addr>"
using a text address from the jbd2 module that would "see" the relevant
structure:
crash> help set
NAME
set - set a process context or internal crash variable
SYNOPSIS
set [[-a] [pid | taskp] | [-c cpu] | -p] | [crash_variable [setting]] | -v
... [ cut ] ...
This command may also be used to set internal crash variables. If no value
argument is entered, the current value of the crash variable is shown. These
are the crash variables, acceptable arguments, and purpose:
... [ cut ] ...
scope text-addr sets the text scope for viewing the definition
of data structures; the "text-addr" argument
must be a kernel or module text address, which
may be expressed symbolically or as a hexadecimal
value.
It sets the internal gdb block scope based upon the text address, but I can't
guarantee that it will always work.
Dave
--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility
