emacs-pretest-bug
[Top][All Lists]
Advanced

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

Re: Segfault and font corruption in menu under Windows


From: Eli Zaretskii
Subject: Re: Segfault and font corruption in menu under Windows
Date: Fri, 04 Aug 2006 13:13:05 +0300

> From: Ralf Angeli <address@hidden>
> Date: Thu, 03 Aug 2006 23:15:38 +0200
> 
> * Eli Zaretskii (2006-08-03) writes:
> 
> > Put a watchpoint to watch *(char *)0x85f988, and see what code
> > modifies it.
> 
> Thanks for the hint.  That's what I get when playing around with it a
> little bit (control characters replaced by strings again):
> 
> Breakpoint 1, w32_wnd_proc (hwnd=0x101f0, msg=43, wParam=0, lParam=552399328) 
> at w32fns.c:3571
> (gdb) p title
> $1 = 0x860720 "G"
> (gdb) delete
> Delete all breakpoints? (y or n) y
> (gdb) watch *(char *)0x860720
> Hardware watchpoint 2: *(char *) 8783648
> (gdb) c
> Continuing.
> Hardware watchpoint 2: *(char *) 8783648
> 
> Old value = 71 'G'
> New value = -18 '\356'
> 0x7c913105 in _libkernel32_a_iname ()

Jason suggested one way of trying to understand whodunit.  Another way
is this: based on looking into this crash back when you reported it,
I'm guessing that we somehow free the strings allocated to hold the
menu items and/or title, and then reuse those strings as if they were
still allocated; in the meantime, some other code, perhaps not even in
Emacs, allocates and writes into the same memory, which would explain
why the watchpoint triggers inside some OS kernel function.  If my
guess is correct, then setting an access watchpoint (the `awatch'
command in GDB) on the address above will show you who frees the
strings, because freeing it involves accessing the address.




reply via email to

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