The following is from ADB, emailed to me on 2022-08-24:
May as well put this in the Issue Tracker - if nothing else, it'll make me look at it again in calmer times.
//------------------------------------------------------------------------------
void __fastcall TChannelForm::InjeSendBtnClick(TObject *Sender)
// The "Inject remote command" button has been smote. Smitten? Smut?
{
Msg_p Z; // Build us a message to send
Z.Key(Q::MONI,Q::INJE,Q::REQ); // Key fields
// Pull in the command string
string cmnd = VCL2STL(InjeCommandEdit->Text);
// On the assumption it's a POETS command
// append a comment. If it isn't, Root
// will bark anyway.
cmnd += " // [Remote monitor]"; // Help to keep track of things
// User defined acknowledgement string
string ack_s = VCL2STL(InjeAckEdit->Text);
Z.Zname(3,ack_s); // Pack it away
Z.Put<char>(1,&cmnd[0],cmnd.size()+1); // -> <char>[1] 'cos OnKeyb expects it
/* The "+1" is a mystery. The short explanation is that it makes an access
overrun error in TMonitorForm::OnMoniInjeAck(..) go away, and as it's just a
overrun for a read for a GUI display element it's hard to see how it could
be
dangerous. Further, it's just one byte, so we can spare it.
More worryingly, I CANNOT reproduce the fault in a test harness, which
points to
a more subtle corruption inside Msg_p. Exactly the same construct is used
elsewhere in the Orchestrator with no problems. Given that the internals of
Msg_p scamper about in a large pre-allocated area of memory under the
control of
a cut-down memory manager that I wrote, the fault is probably ultimately
going
to be mine, but I don't have the bandwidth right now to get in there and
find
and fix it.
*/
MonitorForm->Client.Send(Z.Stream_v());// Stream it
}
//------------------------------------------------------------------------------
The following is from ADB, emailed to me on 2022-08-24:
May as well put this in the Issue Tracker - if nothing else, it'll make me look at it again in calmer times.