Re: [cdt-dev] Resolved: issue with getting the output of gdb command 'in

[Jonah Graham <jonah@xxxxxxxxxxxxxxxx>]

Thanks for reporting back. 

The request monitors in DSF are tricky to get right sometimes. I too have lost hours on occasion debugging an errant request monitor. In case you don't already, make sure to debug with -ea command line option to enable java assertions as that may help. There are also tracing option for executors and monitors that are useful too for the next time. 

Jonah 

On Sat., Jun. 18, 2022, 18:47 Zied Guermazi, <zied.guermazi@xxxxxxxxx> wrote:

hi All,

it was a misunderstanding of the parentRequestMonitor in RequestMonitor. The issue is now solved.

/Zied

On 18.06.22 02:07, Zied Guermazi wrote:

hi

I am extending eclipse to handle gdb record btrace, and display and navigate in instructions and function-calls histories.

I would like to inform the user about the status of the recording and therefore I need to issue the gdb command 'info record'

here is the implementation of the command

public void infoRecord(ICommandControlDMContext context, RequestMonitor rm) { if (fReverseTraceMethod != ReverseDebugMethod.OFF) { getConnection().queueCommand(fCommandFactory.createCLIInfoRecord(context), new DataRequestMonitor<CLIInfoRecordInfo>(getExecutor(), rm) { @Override public void handleFailure() { setResumePending(false); getCache().setContextAvailable(context, true); } @Override protected void handleSuccess() { Integer count = getData().getFunctionsCount(); System.out.println("Recording " + getData().getIsRecording() + ", icount " + getData().getInstructionsCount() + ", fcount " + getData().getFunctionsCount() + ", Replaying " + getData().getIsReplaying() + ", replaying at: " + getData().getReplyingInstruction() + " <=================="); System.out.println("GDBRunControl.handleSuccess DataRequestMonitor"); System.out.println("getDate(): " + getData() + ", " + count); rm.done(); } }); } else { rm.done(); } }

the command is issued properly but I am not able to get the data back.

the only location where the command is additionally consumed is

public void eventReceived(Object output) {

defined in GDBRunControl_7_10.java.

this function was introduced on 01.03.2016 to fix bug 488660.

can this method lead to the consumption of the output and therefore preventing the CLIInfoRecordInfo from getting and processing the output properly?

do you have a suggestion to overcome this issue?

Kind Regards

Zied Guermazi

--

Zied Guermazi founder Trande GmbH Leuschnerstraße 2 69469 Weinheim/Germany Mobile: +491722645127 mailto:zied.guermazi@xxxxxxxxx Trande GmbH Leuschnerstraße 2, D-69469 Weinheim; Telefon: +491722645127 Sitz der Gesellschaft: Weinheim- Registergericht: AG Mannheim HRB 736209 - Geschäftsführung: Zied Guermazi

Confidentiality Note This message is intended only for the use of the named recipient(s) and may contain confidential and/or privileged information. If you are not the intended recipient, please contact the sender and delete the message. Any unauthorized use of the information contained in this message is prohibited.

--

Zied Guermazi founder Trande GmbH Leuschnerstraße 2 69469 Weinheim/Germany Mobile: +491722645127 mailto:zied.guermazi@xxxxxxxxx Trande GmbH Leuschnerstraße 2, D-69469 Weinheim; Telefon: +491722645127 Sitz der Gesellschaft: Weinheim- Registergericht: AG Mannheim HRB 736209 - Geschäftsführung: Zied Guermazi

Confidentiality Note This message is intended only for the use of the named recipient(s) and may contain confidential and/or privileged information. If you are not the intended recipient, please contact the sender and delete the message. Any unauthorized use of the information contained in this message is prohibited.

_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev

Attachment: 7oNUOORA9y8a15mW.png
Description: PNG image