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

display bug , after some commands ,there will be a wrong display #1102

Closed
1 of 9 tasks
bb33bb opened this issue May 12, 2024 · 10 comments
Closed
1 of 9 tasks

display bug , after some commands ,there will be a wrong display #1102

bb33bb opened this issue May 12, 2024 · 10 comments

Comments

@bb33bb
Copy link

bb33bb commented May 12, 2024

GEF+GDB version

manjaro latest
gdb-multiarch                        127 ✘ 
GNU gdb (GDB) 14.2
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word".
GEF for linux ready, type `gef' to start, `gef config' to configure
88 commands loaded and 5 functions added for GDB 14.2 in 0.00ms using Python engine 3.11

Operating System

No response

Describe the issue you encountered

see the picture

Do you read the docs and look at previously closed issues/PRs for similar cases?

No

Architecture impacted

  • X86
  • X64
  • ARM
  • ARM64
  • MIPS
  • MIPS64
  • PPC
  • PPC64
  • RISCV

Describe your issue. Without a proper reproduction step-by-step, your issue will be ignored.

start arm64 qemu
gdb-multiarch
use some command , it wil be ok to see the issue

Minimalist test case

Use this field for a minimal code to compile and spot the issue:

// compile with gcc -fPIE -pic -o my_issue.out my_issue.c
int main(){ return 0; }

You can also provide a Dockerfile if you prefer

Additional context?

2024-05-12_18-44

@bb33bb
Copy link
Author

bb33bb commented May 12, 2024

for example, i am usingthe following command

print *(struct list_head *)0xffff800009b7ccc8

then the out put will be

_print *(_print *(struct list_head *)0xffff800009b7ccc8

print *(
is the wrong output by debuger or cef
everytime , the first len("print *(") of letters will be added to the front of the command you typed
also the wrongly added letters will be highlighted.

@ValekoZ
Copy link
Contributor

ValekoZ commented May 13, 2024

It seems like the problem comes from the boldify line 11237 (and we should have the same issue on the other cases I guess)
Can you try this patch just to check that I'm right, please?

@ValekoZ
Copy link
Contributor

ValekoZ commented May 13, 2024

diff --git a/gef.py b/gef.py
index ce95e20..4d49b2d 100644
--- a/gef.py
+++ b/gef.py
@@ -11234,7 +11234,7 @@ class GefRemoteSessionManager(GefSessionManager):
             if self == GefRemoteSessionManager.RemoteMode.RR:
                 return Color.boldify("(rr) ")
             if self == GefRemoteSessionManager.RemoteMode.GDBSERVER:
-                return Color.boldify("(remote) ")
+                return "(remote) "
             raise AttributeError("Unknown value")

     def __init__(self, host: str, port: int, pid: int =-1, qemu: Optional[pathlib.Path] = None) -> None:

@Grazfather
Copy link
Collaborator

Hm, our colorify makes sure to use normal at the end, and all our codes start with \033, so I don't understand why this would happen. I also don't see it myself. What terminal emulator are you using?

@ValekoZ
Copy link
Contributor

ValekoZ commented May 14, 2024

It is not related to the terminal emulator but to the readline library (which is used by gdb).
You can see it by using the up arrow to go to the previous command multiple times when having a remote connection.
What happens is that ANSI escape codes are counted by the readline library as taking actual columns in the output, while it doesn't. We need to tell it that those chars are special chars that take no place in the output so that when it computes the length of the prompt, it does not take those chars into account.

@Grazfather
Copy link
Collaborator

That's exactly what the \033[xxxm is supposed to do. I've dealt with this before and never see those codes.

@Grazfather
Copy link
Collaborator

I think it's \[ and \] around each code. Can you try that?

@ValekoZ
Copy link
Contributor

ValekoZ commented May 16, 2024

I think you don't understand what the issue is. You can check this thread to understand:
https://stackoverflow.com/questions/50470933/readline-confused-by-ansi-escape-sequences
That's actually what I did, by just copying what is already done on the gef> part of the prompt.

@Grazfather
Copy link
Collaborator

I understand the issue. I have \[ and \] in my bashrc prompt to remediate it. Anyway, we'd probably only need it on the gef> part, as well as (remote) and the other prompts we do.

hugsy pushed a commit that referenced this issue May 26, 2024
## Description

Fix bug described in #1102
@hugsy
Copy link
Owner

hugsy commented May 26, 2024

Closing as #1103 was merged

@hugsy hugsy closed this as completed May 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants