[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#39962: 27.0.90; Crash in Emacs 27.0.90

From: Paul Eggert
Subject: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Tue, 17 Mar 2020 13:59:04 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1

Although I haven't been following this in detail, I'd like to suggest trying a GDB watchpoint to find the bug. Watchpoints have been invaluable to me when I debug garbage-collector and other memory management issues.

Say you have a repeatable way to make the problem happen. You discover that some random part of Emacs (you don't know what) has zapped the 'next' field of some data structure D to make it a null pointer. You want to find out who zapped it.

To do that, first compute the address of the field you're interested in:

(gdb) p &D->next

You'll get a number like 0x16082a730.


(gdb) watch *(void *)0x16082a730
(gdb) run

The last command re-runs Emacs, and should stop each time the memory location at 0x16082a730 changes. If you're lucky, this will be just a few times and you can figure out who's zapping D->next. If you're unlucky you can come up with a fancier watchpoint that may do the trick. (I'm using a plain 'watch' rather than a 'watch -l' in the example above, merely to keep things simple.)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]