Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Specific -var-create in core dump debugging is incredible slow #1479

Open
borjamunozf opened this issue Oct 3, 2024 · 1 comment
Open

Specific -var-create in core dump debugging is incredible slow #1479

borjamunozf opened this issue Oct 3, 2024 · 1 comment

Comments

@borjamunozf
Copy link

borjamunozf commented Oct 3, 2024

Hello.

Summary
Debugging a C++ Core dump spent too much time waiting for the result of an specific -var-create (cutFrames).

The context is explained in this thread in C++ debugger extension.

GDB command line does not suffer of this problem, overall debug took ~2 minutes.

Gathering debug info from MIENGINE

I was able to setup the debugger to debug OpenDebugAD7 process.

  • Stepping through the code flow

Results results = await MICommandFactory.VarCreate(n, thread.Id, (uint)level, 0, ResultClass.None);

  • Command: 1106-var-create - * "cutFrames"
  • After executing the CmdAsyncInternal I lost what's going on:

public async Task<Results> CmdAsync(string command, ResultClass expectedResultClass)
{
await _commandLock.AquireShared();
try
{
return await CmdAsyncInternal(command, expectedResultClass);
}
finally
{
_commandLock.ReleaseShared();
}
}

  • Status of waitingOperations:
    Pasted image 20241003003909

  • Step into MITransport > StreamTransport > Task.Wait(token) (execute the task?) and takes minutes to reach the next line -> return task.Result;

  • After it returned, continuing stepping over I see this information on the overall status of the Debugger. There are two different exceptions, but I dont know if they're real or important at all for MICore.LocalTransport. _InvalidOperation*, process must exist before requested information can be determined.

imagen

  • Nexts steps shows a ParseIssue? for it also shows the same for the other args (which seems to respond quickly)
    imagen

Could you help me to identify what's going on? Any idea?
Thanks.

@borjamunozf
Copy link
Author

Investigation ongoing:

  • It could be that is not strictly a problem with MIEngine, but with GDB/MI.

Running this sequence of cmds:

gdb-multiarch --interpreter mi <binary> <coreDump>
-stack-select frame 4
- var-create  - * "cutFrames"

the faulty var-create - * "cutFrames" takes ~5-6 minutes!

I will open a bug/ticket in GDB/MI also, let's see if I can get any help :/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant