mdb cross-module dcmd calls fail in CTF lookup
The mdb module for smbsrv fails in "smbreq -v" after #3467 with:
> ffffff01dd308390 ::smbreq -v SMB request information (ffffff01dd308390): first SMB COM: 160 (SMB_COM_NT_TRANSACT) current SMB COM: 160 (SMB_COM_NT_TRANSACT) state: 5 (WAITING_FCN1) TID(tree): 2 (ffffff01dd911060) UID(user): 1 (ffffff01dcdc8938) FID(file): 1 (ffffff01dd861be8) PID: 6768 MID: 0x481 waiting time: 0 running time: 20 worker thread: 0 mdb: couldn't find ctf data for type mdb_findstack_kthread_t in mdb module smbsrv
Updated by Gordon Ross over 4 years ago
The problem is in this call:
mdb_call_dcmd("findstack", addr, DCMD_ADDRSPEC, 1, &cmdarg);
where in the call to mdb_ctf_vread, we find a module here:
and the module has CTF data, but the module returned by mdb_get_module is the "smbsrv"
module. We're running the "genunix`findstack" dcmd here, so that's wrong.
In general, the two calls to mdb_call_idcmd in mdb_modapi.c need to handle
cases were one mdb module is calling a dcmd in another mdb module.
This appears to be a regression after #3467 where findstack started using
I have a fix that makes the two callers of mdb_call_idcmd in mdb_modapi.c setup a
more correct mdb.m_frame->f_cp (with a command representing the dcmd that's
being called). That seems to work.
I also considered pushing a new mdb "frame" there, but that seems unnecessary.
Out for review: https://www.illumos.org/rb/r/304/
Updated by Electric Monk about 4 years ago
- Status changed from In Progress to Closed
- % Done changed from 0 to 100
commit ab2e2ee8084b5368a6eff4d96fbad03a661c8ace Author: Gordon Ross <email@example.com> Date: 2017-01-14T15:37:37.000Z 7687 mdb cross-module dcmd calls fail in CTF lookup Reviewed by: Evan Layton <firstname.lastname@example.org> Reviewed by: Matt Barden <email@example.com> Reviewed by: Robert Mustacchi <firstname.lastname@example.org> Approved by: Dan McDonald <email@example.com>