internlm/SWE-Fixer-Train-110K huggingface dataset:
Repository: pwndbg/pwndbg

Issue:
telescope skipping repeated vals is incorrect for last elements
@anthraxx see this pls, for count being 16 we are not showing the repeated value :(
```
pwndbg> telescope 0x21c108086888 15
00:0000│  0x21c108086888 ◂— 0x3ff199999999999a
01:0008│  0x21c108086890 ◂— 0x3ff3333333333333
02:0010│  0x21c108086898 ◂— 0x3ff4cccccccccccd
03:0018│  0x21c1080868a0 ◂— 0x3ff6666666666666
04:0020│  0x21c1080868a8 ◂— 0x3ff8000000000000
05:0028│  0x21c1080868b0 ◂— 0x80cd3f9082858b9
06:0030│  0x21c1080868b8 ◂— 0x80cd44108086881
07:0038│  0x21c1080868c0 ◂— 0x804222d08283139
08:0040│  0x21c1080868c8 ◂— 0x2000080b7191
09:0048│  0x21c1080868d0 ◂— 0x804222d08282d49
0a:0050│  0x21c1080868d8 ◂— 0x100804222d
0b:0058│  0x21c1080868e0 ◂— 0xa0c01000000000
0c:0060│  0x21c1080868e8 ◂— 0x947770000039f2
0d:0068│  0x21c1080868f0 ◂— 0x2000039f2
0e:0070│  0x21c1080868f8 ◂— 0x0
pwndbg> telescope 0x21c108086888 16
00:0000│  0x21c108086888 ◂— 0x3ff199999999999a
01:0008│  0x21c108086890 ◂— 0x3ff3333333333333
02:0010│  0x21c108086898 ◂— 0x3ff4cccccccccccd
03:0018│  0x21c1080868a0 ◂— 0x3ff6666666666666
04:0020│  0x21c1080868a8 ◂— 0x3ff8000000000000
05:0028│  0x21c1080868b0 ◂— 0x80cd3f9082858b9
06:0030│  0x21c1080868b8 ◂— 0x80cd44108086881
07:0038│  0x21c1080868c0 ◂— 0x804222d08283139
08:0040│  0x21c1080868c8 ◂— 0x2000080b7191
09:0048│  0x21c1080868d0 ◂— 0x804222d08282d49
0a:0050│  0x21c1080868d8 ◂— 0x100804222d
0b:0058│  0x21c1080868e0 ◂— 0xa0c01000000000
0c:0060│  0x21c1080868e8 ◂— 0x947770000039f2
0d:0068│  0x21c1080868f0 ◂— 0x2000039f2
0e:0070│  0x21c1080868f8 ◂— 0x0
pwndbg> telescope 0x21c108086888 17
00:0000│  0x21c108086888 ◂— 0x3ff199999999999a
01:0008│  0x21c108086890 ◂— 0x3ff3333333333333
02:0010│  0x21c108086898 ◂— 0x3ff4cccccccccccd
03:0018│  0x21c1080868a0 ◂— 0x3ff6666666666666
04:0020│  0x21c1080868a8 ◂— 0x3ff8000000000000
05:0028│  0x21c1080868b0 ◂— 0x80cd3f9082858b9
06:0030│  0x21c1080868b8 ◂— 0x80cd44108086881
07:0038│  0x21c1080868c0 ◂— 0x804222d08283139
08:0040│  0x21c1080868c8 ◂— 0x2000080b7191
09:0048│  0x21c1080868d0 ◂— 0x804222d08282d49
0a:0050│  0x21c1080868d8 ◂— 0x100804222d
0b:0058│  0x21c1080868e0 ◂— 0xa0c01000000000
0c:0060│  0x21c1080868e8 ◂— 0x947770000039f2
0d:0068│  0x21c1080868f0 ◂— 0x2000039f2
0e:0070│  0x21c1080868f8 ◂— 0x0
0f:0078│  0x21c108086900 ◂— 0x0
10:0080│  0x21c108086908 ◂— 0x2208042205
pwndbg> 
```


Discussion:
Hm interesting, will take a look at the code path and open a fix PR.
We need more (functional) unit tests xD


Resolving patch:
diff --git a/pwndbg/commands/telescope.py b/pwndbg/commands/telescope.py
--- a/pwndbg/commands/telescope.py
+++ b/pwndbg/commands/telescope.py
@@ -131,6 +131,7 @@ def collapse_repeating_values():
 
         result.append(line)
 
+    collapse_repeating_values()
     telescope.offset += i
     telescope.last_address = addr
 


Test patch:
Repository: pwndbg/pwndbg

Issue:
heap command failed on glibc 2.34
### Description

I try to use pwndbg to inspect heap in the new glibc 2.34 (Ubuntu GLIBC 2.34-0ubuntu1).  
But it shows the message below:
```python3
pwndbg> heap
'heap': Iteratively print chunks on a heap, default to the current thread's active heap.
Traceback (most recent call last):
  File "/home/wangjihe/gdb-plugins/pwndbg/pwndbg/commands/__init__.py", line 130, in __call__
    return self.function(*args, **kwargs)
  File "/home/wangjihe/gdb-plugins/pwndbg/pwndbg/commands/__init__.py", line 221, in _OnlyWhenRunning
    return function(*a, **kw)
  File "/home/wangjihe/gdb-plugins/pwndbg/pwndbg/commands/__init__.py", line 259, in _OnlyWithLibcDebugSyms
    return function(*a, **kw)
  File "/home/wangjihe/gdb-plugins/pwndbg/pwndbg/commands/__init__.py", line 238, in _OnlyWhenHeapIsInitialized
    if pwndbg.heap.current.is_initialized():
  File "/home/wangjihe/gdb-plugins/pwndbg/pwndbg/heap/ptmalloc.py", line 552, in is_initialized
    return pwndbg.memory.s32(addr) > 0
  File "/home/wangjihe/gdb-plugins/pwndbg/pwndbg/memory.py", line 265, in s32
    return readtype(pwndbg.typeinfo.int32, addr)
  File "/home/wangjihe/gdb-plugins/pwndbg/pwndbg/memory.py", line 83, in readtype
    return int(gdb.Value(addr).cast(gdb_type.pointer()).dereference())
TypeError: Could not convert Python object: None.
```

It seems that it's caused by some symbol changes in the new glibc.  
Before 2.34, glibc will export `__malloc_initialized` as `__libc_malloc_initialized` in `include/malloc.h`.  
```c
/* In the GNU libc we rename the global variable
   `__malloc_initialized' to `__libc_malloc_initialized'.  */
#define __malloc_initialized __libc_malloc_initialized
/* Nonzero if the malloc is already initialized.  */
extern int __malloc_initialized attribute_hidden;
```
But in glibc 2.34, they've removed it.

The simple solution I've found is to modify `pwndbg/heap/ptmalloc.py`, check if `__libc_malloc_initialized` exists, if not use `__malloc_initialized` instead.




Discussion:

Resolving patch:
diff --git a/pwndbg/heap/ptmalloc.py b/pwndbg/heap/ptmalloc.py
--- a/pwndbg/heap/ptmalloc.py
+++ b/pwndbg/heap/ptmalloc.py
@@ -549,6 +549,8 @@ def largebin_index(self, sz):
 
     def is_initialized(self):
         addr = pwndbg.symbol.address('__libc_malloc_initialized')
+        if addr is None:
+            addr = pwndbg.symbol.address('__malloc_initialized')
         return pwndbg.memory.s32(addr) > 0
 
     def libc_has_debug_syms(self):


Test patch:
Repository: pwndbg/pwndbg

Issue:
xinfo command doesn't like anonymous page names
The naming of anonymous memory pages introduced in 462eb53 is cool but it doesn't play nicely with the `xinfo` command.
The following figure shows `xinfo` behaving correctly when displaying info on a regular mapping, followed by an error when used with an anonymous mapping.

![xinfo](https://user-images.githubusercontent.com/16000770/133327381-c4f9d13b-5d20-4fd3-80b5-01aad51a5387.png)

`xinfo` uses `page.is_memory_mapped_file()` to determine whether a page is file backed, this in turn is based on the object name:
https://github.com/pwndbg/pwndbg/blob/648c7f014e25a2944ee40891000fb43031182e51/pwndbg/memory.py#L409-L411

Because 462eb53 names anonymous pages that previously had no name, the above function reports them as memory mapped files which `xinfo` tries to open.

A possible solution could be to enclose the anonymous page names in square brackets, which `is_memory_mapped_file()` ignores.


Discussion:
Yeah, I saw a similar code with `'['` check before. I think we should rename anon pages to `[<address>]` instead

Resolving patch:
diff --git a/pwndbg/vmmap.py b/pwndbg/vmmap.py
--- a/pwndbg/vmmap.py
+++ b/pwndbg/vmmap.py
@@ -212,7 +212,7 @@ def proc_pid_maps():
         try:
             inode, objfile = inode_objfile.split(None, 1)
         except:
-            objfile = 'anon_' + start[:-3]
+            objfile = '[anon_' + start[:-3] + ']'
 
         start  = int(start, 16)
         stop   = int(stop, 16)


Test patch:
Repository: pwndbg/pwndbg

Issue:
Typo in dd command: dump N dwrods.
<!--
Before reporting a new issue, make sure that we do not have any duplicates already open.
If there is one it might be good to take part in the discussion there.

Please make sure you have checked that the issue persists on LATEST pwndbg version.

Below is a template for BUG REPORTS.
Don't include it if this is a FEATURE REQUEST.
-->


### Description

<!--
Briefly describe the problem you are having in a few paragraphs.
-->

There is typo in the following command:
```
pwndbg> pwndbg dump
[...snip...]
dd                   Starting at the specified address, dump N dwrods.
```

### Steps to reproduce

<!--
What do we have to do to reproduce the problem?
If this is connected to particular C/asm code, 
please provide the smallest C code that reproduces the issue.
-->
1. Launch pwndbg
2.  Type `pwndbg dump`

### My setup

<!--
Show us your gdb/python/pwndbg/OS/IDA Pro version (depending on your case).

NOTE: We are currently supporting only Ubuntu installations.
It is known that pwndbg is not fully working e.g. on Arch Linux (the heap stuff is not working there).
If you would like to change this situation - help us improving pwndbg and supporting other distros!

This can be displayed in pwndbg through `version` command.

If it is somehow unavailable, use:
* `show version` - for gdb
* `py import sys; print(sys.version)` - for python
* pwndbg version/git commit id
-->
```
GNU gdb (Ubuntu 8.1.1-0ubuntu1) 8.1.1
Copyright (C) 2018 Free Software Foundation, Inc.
```



Discussion:

Resolving patch:
diff --git a/pwndbg/commands/windbg.py b/pwndbg/commands/windbg.py
--- a/pwndbg/commands/windbg.py
+++ b/pwndbg/commands/windbg.py
@@ -54,7 +54,7 @@ def dw(address, count=32):
     return dX(2, address, count, repeat=dw.repeat)
 
 
-parser = argparse.ArgumentParser(description="Starting at the specified address, dump N dwrods.")
+parser = argparse.ArgumentParser(description="Starting at the specified address, dump N dwords.")
 parser.add_argument("address", type=int, help="The address to dump from.")
 parser.add_argument("count", type=int, default=16, nargs="?", help="The number of dwords to dump.")
 @pwndbg.commands.ArgparsedCommand(parser)


Test patch:
Repository: pwndbg/pwndbg

Issue:
add-symbol-file should not specify a base address
This happens when connecting to a remote target:
```
hacker@babyrop_level10:~$ gdb -ex 'target remote :1234'
...
add-symbol-file /tmp/tmp_yea7f3g/babyrop_level10.0 0x555555554000
...
pwndbg> b main
Breakpoint 1 at 0x555555555581 (2 locations)
pwndbg> info b
Num     Type           Disp Enb Address            What
1       breakpoint     keep y   <MULTIPLE>         
1.1                         y   0x0000555555555581 <main>
1.2                         y   0x00005555555567c1 
```
This double breakpoint results in `\xcc` bytes incorrectly polluting memory, and I've seen this corrupt the GOT and crash my program as a result.

https://github.com/pwndbg/pwndbg/blob/05036defa01d4d47bfad56867f53470a29fcdc89/pwndbg/symbol.py#L261

Why is the base address being specified here? According to the help info for `add-symbol-file`, if anything is specified for `[ADDR]`, it should be the location of the `.text` section.

```
(gdb) help add-symbol-file
Load symbols from FILE, assuming FILE has been dynamically loaded.
Usage: add-symbol-file FILE [-readnow | -readnever] [-o OFF] [ADDR] [-s SECT-NAME SECT-ADDR]...
ADDR is the starting address of the file's text.
Each '-s' argument provides a section name and address, and
should be specified if the data and bss segments are not contiguous
with the text.  SECT-NAME is a section name to be loaded at SECT-ADDR.
OFF is an optional offset which is added to the default load addresses
of all sections for which no other address was specified.
The '-readnow' option will cause GDB to read the entire symbol file
immediately.  This makes the command slower, but may make future operations
faster.
The '-readnever' option will prevent GDB from reading the symbol file's
symbolic debug information.
```

If we just omit the address, `gdb` will automatically find the `.text` section and use that address. Things would probably fail if there isn't a `.text` section defined, but I'm not really sure what the correct solution would be in this case anyways.


Discussion:
I just realized that this is the same issue as https://github.com/pwndbg/pwndbg/issues/177.

I'm not really understanding why this issue has not yet been resolved? The current behavior is incorrect. Omitting the address fixes the problem.

Resolving patch:
diff --git a/pwndbg/symbol.py b/pwndbg/symbol.py
--- a/pwndbg/symbol.py
+++ b/pwndbg/symbol.py
@@ -258,7 +258,7 @@ def add_main_exe_to_symbols():
     path = mmap.objfile
     if path and (pwndbg.arch.endian == pwndbg.arch.native_endian):
         try:
-            gdb.execute('add-symbol-file %s %#x' % (path, addr), from_tty=False, to_string=True)
+            gdb.execute('add-symbol-file %s' % (path,), from_tty=False, to_string=True)
         except gdb.error:
             pass
 


Test patch:
Repository: pwndbg/pwndbg

Issue:
Define $heap_base variable once the heap has been initialized
While commands like `vis_heap_chunks` are great, they often aren't very usable once the heap becomes corrupted. At this point I often have to do something like `x/100xg 0x55555679a000` where 0x55555679a000 is the heap base address I got from running the `heap` or `vmmap` commands.

While this works, it would be much more convenient if a `$heap_base` variable was automatically defined as soon as the heap was initialized (or at the very least, after the first successful run of some heap command). Then I could reuse commands from my GDB history even when addresses change with ASLR, and I can even use this variable in GDB scripts when launching the binary from pwntools, which will let me dump a lot of useful debugging information about the heap automatically from my exploit script.

If something like this already exists, please let me know. Otherwise, does it make sense to add this to pwndbg?


Discussion:

Resolving patch:
diff --git a/pwndbg/commands/heap.py b/pwndbg/commands/heap.py
--- a/pwndbg/commands/heap.py
+++ b/pwndbg/commands/heap.py
@@ -106,6 +106,10 @@ def heap(addr=None, verbose=False, simple=False):
     top_chunk = arena['top']
     ptr_size = allocator.size_sz
 
+    # Store the heap base address in a GDB variable that can be used in other
+    # GDB commands
+    gdb.execute('set $heap_base=0x{:x}'.format(heap_region.start))
+
     # Calculate where to start printing; if an address was supplied, use that,
     # if this heap belongs to the main arena, start at the beginning of the
     # heap's mapping, otherwise, compensate for the presence of a heap_info


Test patch:
Repository: pwndbg/pwndbg

Issue:
Better marking of modified registers
Currently, if a register was modified between two stops, we show it `context regs` by prefixing it with an asterisks.

I have seen that gef does this by marking the register as red, and showing this in its legend:
<img width="1233" alt="image" src="https://user-images.githubusercontent.com/10009354/185767836-198276f8-2592-446f-8d1b-b148acb49b2f.png">

Perhaps we should also mark the register with some color? :)


Discussion:

Resolving patch:
diff --git a/pwndbg/color/context.py b/pwndbg/color/context.py
--- a/pwndbg/color/context.py
+++ b/pwndbg/color/context.py
@@ -29,7 +29,7 @@
 config_banner_color = theme.ColoredParameter("banner-color", "blue", "color for banner line")
 config_banner_title = theme.ColoredParameter("banner-title-color", "none", "color for banner title")
 config_register_changed_color = theme.ColoredParameter(
-    "context-register-changed-color", "normal", "color for registers label (change marker)"
+    "context-register-changed-color", "red", "color for registers label (change marker)"
 )
 config_register_changed_marker = theme.Parameter(
     "context-register-changed-marker", "*", "change marker for registers label"
diff --git a/pwndbg/commands/context.py b/pwndbg/commands/context.py
--- a/pwndbg/commands/context.py
+++ b/pwndbg/commands/context.py
@@ -518,8 +518,10 @@ def get_regs(*regs):
 
         value = pwndbg.gdblib.regs[reg]
 
-        # Make the register stand out
+        # Make the register stand out and give a color if changed
         regname = C.register(reg.ljust(4).upper())
+        if reg in changed:
+            regname = C.register_changed(regname)
 
         # Show a dot next to the register if it changed
         change_marker = "%s" % C.config_register_changed_marker
@@ -534,7 +536,6 @@ def get_regs(*regs):
             desc = pwndbg.chain.format(value)
 
         result.append("%s%s %s" % (m, regname, desc))
-
     return result
 
 


Test patch:
Repository: pwndbg/pwndbg

Issue:
`leakfind` should default to `$sp`
The first argument to `leakfind` is required, but it should just default to `$sp` like `probeleak` does.


Discussion:
@gsingh93 I can work on this issue. Can you refer to me how `probeleak` works and i can do it
Thanks! This should be pretty easy. If you take a look at `commands/probeleak.py`, you can see the `address` argument uses `nargs` and `default`. We just need to do the same thing in `commands/leakfind.py`.
@gsingh93 in that case can you assign this to me?


Resolving patch:
diff --git a/pwndbg/commands/leakfind.py b/pwndbg/commands/leakfind.py
--- a/pwndbg/commands/leakfind.py
+++ b/pwndbg/commands/leakfind.py
@@ -60,7 +60,9 @@ def dbg_print_map(maps):
 and are a maximum length of 6.
 """
 parser.formatter_class = argparse.RawDescriptionHelpFormatter
-parser.add_argument("address", help="Starting address to find a leak chain from")
+parser.add_argument(
+    "address", nargs="?", default="$sp", help="Starting address to find a leak chain from"
+)
 parser.add_argument(
     "-p",
     "--page_name",


Test patch:
Repository: pwndbg/pwndbg

Issue:
ipi doesn't work with multiline inputs
TL;DR:
<img width="550" alt="image" src="https://user-images.githubusercontent.com/10009354/193942063-af410d4d-3cdd-4bcb-a102-9bb87d101656.png">

```
pwndbg> ipi

In [1]: from ctypes import *

In [2]: class A(LittleEndianStructure):
   ...:     a = LittleEndianStructure
   ...:
---------------------------------------------------------------------------
NameError                                 Traceback (most recent call last)
<ipython-input-2-814bd2a1d7ec> in <module>
----> 1 class A(LittleEndianStructure):
      2     a = LittleEndianStructure
      3

<ipython-input-2-814bd2a1d7ec> in A()
      1 class A(LittleEndianStructure):
----> 2     a = LittleEndianStructure
      3

NameError: name 'LittleEndianStructure' is not defined

In [3]: ctypes
---------------------------------------------------------------------------
NameError                                 Traceback (most recent call last)
<ipython-input-3-8c9cdb26e3f3> in <module>
----> 1 ctypes

NameError: name 'ctypes' is not defined

In [4]: LittleEndianStructure
Out[4]: _ctypes.Structure

In [5]: def foo():
   ...:     return LittleEndianStructure
   ...:

In [6]: foo()
---------------------------------------------------------------------------
NameError                                 Traceback (most recent call last)
<ipython-input-6-c19b6d9633cf> in <module>
----> 1 foo()

<ipython-input-5-0b19aa36e370> in foo()
      1 def foo():
----> 2     return LittleEndianStructure
      3

NameError: name 'LittleEndianStructure' is not defined

In [7]:
```


Discussion:
Whereas this works in pure GDB python interpreter:
```
pwndbg> pi
>>> from ctypes import *
>>> class A(LittleEndianStructure):
...   a = LittleEndianStructure
...
>>> A.a
<class '_ctypes.Structure'>
>>>
```
https://stackoverflow.com/questions/35161324/how-to-make-imports-closures-work-from-ipythons-embed

Resolving patch:
diff --git a/pwndbg/commands/ipython_interactive.py b/pwndbg/commands/ipython_interactive.py
--- a/pwndbg/commands/ipython_interactive.py
+++ b/pwndbg/commands/ipython_interactive.py
@@ -43,6 +43,6 @@ def ipi():
         code4ipython = """import jedi
 import pwn
 jedi.Interpreter._allow_descriptor_getattr_default = False
-IPython.embed(colors='neutral',banner1='',confirm_exit=False,simple_prompt=False)
+IPython.embed(colors='neutral',banner1='',confirm_exit=False,simple_prompt=False, user_ns=globals())
 """
         gdb.execute(f"py\n{code4ipython}")


Test patch:
Repository: pwndbg/pwndbg

Issue:
pwndbg.gdblib.arch.current is wrong if executed in a pwntools gdbscript command
TL;DR: This should not fail, but does so, because the `patch` command fetches `pwndbg.gdblib.arch.current` which for some reason is wrong/not updated.


```py
from pwn import *

gdbscript = '''
tbreak main
patch $rip 'xor rax, rax'
continue
'''

p = gdb.debug('/bin/ls', gdbscript=gdbscript)

p.interactive()
```

Stacktrace:
```
Traceback (most recent call last):
  File "/home/dc/tools/pwndbg/pwndbg/commands/__init__.py", line 145, in __call__
    return self.function(*args, **kwargs)
  File "/home/dc/tools/pwndbg/pwndbg/commands/__init__.py", line 216, in _OnlyWhenRunning
    return function(*a, **kw)
  File "/home/dc/tools/pwndbg/pwndbg/commands/patch.py", line 25, in patch
    new_mem = asm(ins, arch=pwndbg.gdblib.arch.current)
  File "/home/dc/.virtualenvs/pwn/lib/python3.8/site-packages/pwnlib/context/__init__.py", line 1444, in setter
    raise AttributeError("Invalid arch/bits combination: %s/%s" % (arch, bits))
AttributeError: Invalid arch/bits combination: i386/64

If that is an issue, you can report it on https://github.com/pwndbg/pwndbg/issues
(Please don't forget to search if it hasn't been reported before)
To generate the report and open a browser, you may run `bugreport --run-browser`
PS: Pull requests are welcome
> /home/dc/.virtualenvs/pwn/lib/python3.8/site-packages/pwnlib/context/__init__.py(1444)setter()
-> raise AttributeError("Invalid arch/bits combination: %s/%s" % (arch, bits))
(Pdb) p arch, bits
('i386', 64)
(Pdb) 
```


Discussion:

Resolving patch:
diff --git a/pwndbg/commands/patch.py b/pwndbg/commands/patch.py
--- a/pwndbg/commands/patch.py
+++ b/pwndbg/commands/patch.py
@@ -22,7 +22,7 @@
 @pwndbg.commands.ArgparsedCommand(parser)
 @pwndbg.commands.OnlyWhenRunning
 def patch(address, ins):
-    new_mem = asm(ins, arch=pwndbg.gdblib.arch.current)
+    new_mem = asm(ins)
 
     old_mem = pwndbg.gdblib.memory.read(address, len(new_mem))
 
@@ -68,8 +68,8 @@ def patch_list():
 
     print(message.hint("Patches:"))
     for addr, (old, new) in patches.items():
-        old_insns = disasm(old, arch=pwndbg.gdblib.arch.current)
-        new_insns = disasm(new, arch=pwndbg.gdblib.arch.current)
+        old_insns = disasm(old)
+        new_insns = disasm(new)
 
         print(
             message.hint("Patch at"),


Test patch:
Repository: pwndbg/pwndbg

Issue:
`pwndbg.gdblib.symbol.address` fail to handle the thread-local variables
<img width="1289" alt="截圖 2022-10-11 下午4 46 56" src="https://user-images.githubusercontent.com/61896187/195043471-185d98a1-0df4-43af-ba68-54f8e0853e31.png">

`pwndbg.gdblib.symbol.address('tcache')` will get error instead of return `None`.

Seems like it's because the error starts with `Cannot find thread-local storage` instead of `Cannot find thread-local variables`, so the following line fails to skip it:

https://github.com/pwndbg/pwndbg/blob/478a569cb3bef11f7011cd0a2f374d53ce5997fd/pwndbg/gdblib/symbol.py#L214-L217

cc: @gsingh93 


Discussion:

Resolving patch:
diff --git a/pwndbg/gdblib/symbol.py b/pwndbg/gdblib/symbol.py
--- a/pwndbg/gdblib/symbol.py
+++ b/pwndbg/gdblib/symbol.py
@@ -211,7 +211,7 @@ def address(symbol: str) -> int:
         # If we try to look up a TLS variable when there is no TLS, this
         # exception occurs. Ideally we should come up with a way to check for
         # this case before calling `gdb.lookup_symbol`
-        skipped_exceptions.append("Cannot find thread-local variables")
+        skipped_exceptions.append("Cannot find thread-local")
 
         if all(x not in str(e) for x in skipped_exceptions):
             raise e


Test patch: