GDB command call doesn't trigger any gdb.Event

[rednhot]

• Did you use the latest version of GEF from dev branch?
• Is your bug specific to GEF (not GDB)? - Try to reproduce it running gdb -nx
• Did you read the documentation first?
• Did you check issues (including
  the closed ones) - and the PR?

Step 1: Describe your environment

• Operating System / Distribution: Gentoo Hardened 5.16.5-gentoo-x86_64
• Architecture: x86_64
• GEF version (including the Python library version) run version in GEF.

gef➤  version
GEF: rev:2b7f31515a3638718b133e0d3b096aedeef5518c (Git - clean)
SHA256(/var/tmp/test/gef/gef.py): 767fcae12cac4cc6dbd3a0b2f51ad6b66f40ed72be199f256ed6c85aed44a70f
GDB: 11.2
GDB-Python: 3.9

Step 2: Describe your problem

heap bins doesn't show the real state of the heap when using gdb commands like call free and call malloc. After using them,
heap bins shows wrong information.

For example. when I execute call (void*) malloc(0x10) it returns the chunk which was just in fastbin. Nevertheless, when I use heap bins after that, the chunk still show up in the output, even though the count has decreased.

Steps to reproduce

1. Call malloc(0x10) from the binary.
2. Call free(<chunk_from_step1>) from the binary.
3. Use call (void*) malloc(0x10) from inside of gdb.
4. Use heap bins and see, that tcachebins are not empty.

Minimalist test case

test.c

#include <stdlib.h>

int main(void)
{
    char *p;

    p = malloc(0x10);
    free(p);
} // it's the 9th line

gdbcommands.txt

!cc -g -o test test.c
gef config context.enable False
file ./test
b 9
run
heap bins
call (void*)malloc(0x10)
heap bins

Command line

gdb -x gdbcommands.txt

Expected results

fastbin should be emptied like in the case where we malloc-ed the same chunk from inside the binary.

[hugsy]

It looks like a UI problem. What if you clear the caches after the 2nd malloc call but before the 2nd heap bins?

[rednhot]

It looks like a UI problem. What if you clear the caches after the 2nd malloc call but before the 2nd heap bins?

How can I do it, could you guide me please?

[hugsy]

gef➤ reset-cache
would be the simplest way

[rednhot]

gef➤ reset-cache would be the simplest way

Well, that worked, thanks! Nevertheless, help reset-cache says that this command exists for debugging and testing, so it shouldn't be used under normal conditions, like in my case. Or am i wrong?

[hugsy]

I wasn't saying there isn't a bug, just trying to identify it. Yeah, normal usage should not require the use of reset-cache as we (normally) should handle the cases where the cache must be flushed partially or in full.
Normally GEF detects changes of registers or memory through the GDB event hook but it seems direct function call (using call) triggers any of those event so it's hard for us to detect the change.
I'll keep this ticket open to see if we can find an acceptable solution to this.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. You can reopen it by adding a comment to this issue.

[stale]

This issue has been automatically closed because it has not had recent activity. If you are the owner of this issue, you can either re-open it and provide a more complete description; or create a new issue. Thank you for your contributions.