Re: 4 week-old pretest bugs
So, in order for BLOCK_INPUT to work reliably, it seems that interrupt_input_blocked should be declared as volatile (or maybe `volatile sig_atomic_t' instead of `volatile int') because it is accessed from a signal handler. Isn't it the case that the C spec calls for this to be volatile? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: 4 week-old pretest bugs
Richard Stallman skrev: So, in order for BLOCK_INPUT to work reliably, it seems that interrupt_input_blocked should be declared as volatile (or maybe `volatile sig_atomic_t' instead of `volatile int') because it is accessed from a signal handler. Isn't it the case that the C spec calls for this to be volatile? Quote form the C standard: The type defined is sig_atomic_t which is the (possibly volatile-qualified) integer type of an object that can be accessed as an atomic entity, even in the presence of asynchronous interrupts. However, Neither glibc or Solaris has volatile in the definition. I think the thing guaranteed is accessed, not modified. Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: 4 week-old pretest bugs
I think volatile int is OK, I'm sure some systems don't define sig_atomic_t. We could have configure determine whether sig_atomic_t exists, but first let's try `volatile int' and see if that is enough. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: 4 week-old pretest bugs
YAMAMOTO Mitsuharu [EMAIL PROTECTED] writes: Could you test if the following patch affects the stability? That seems to be fine, but then, the problem has already been fixed by a previous patch. I can't tell whether your patch has improved things or not. Behaviour looks the same with or without it - ie. fine. I'm not sure, but I think this is the change which fixed it: 2007-01-11 Jan Djärv [EMAIL PROTECTED] * alloc.c (BLOCK_INPUT_ALLOC, UNBLOCK_INPUT_ALLOC): Use pthread_equal, block/unblock SIGIO. Should I try backing that change out and seeing whether your patch alone fixes it? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: 4 week-old pretest bugs
On Wed, 24 Jan 2007 23:27:06 +0100, Chris Moore [EMAIL PROTECTED] said: I can't tell whether your patch has improved things or not. Behaviour looks the same with or without it - ie. fine. I'm not sure, but I think this is the change which fixed it: 2007-01-11 Jan Djärv [EMAIL PROTECTED] * alloc.c (BLOCK_INPUT_ALLOC, UNBLOCK_INPUT_ALLOC): Use pthread_equal, block/unblock SIGIO. Should I try backing that change out and seeing whether your patch alone fixes it? No. Actually, my patch backs out the essential part (the latter one) of the above change. So, in order for BLOCK_INPUT to work reliably, it seems that interrupt_input_blocked should be declared as volatile (or maybe `volatile sig_atomic_t' instead of `volatile int') because it is accessed from a signal handler. YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: 4 week-old pretest bugs
YAMAMOTO Mitsuharu skrev: So, in order for BLOCK_INPUT to work reliably, it seems that interrupt_input_blocked should be declared as volatile (or maybe `volatile sig_atomic_t' instead of `volatile int') because it is accessed from a signal handler. I think volatile int is OK, I'm sure some systems don't define sig_atomic_t. Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: 4 week-old pretest bugs
On Mon, 15 Jan 2007 00:01:49 +0100, Chris Moore [EMAIL PROTECTED] said:
If not, I'm more than happy to run any test cases you would like me
to try. I've tried debugging it in various ways myself, but the
timing seems to be so touchy that any attempt to observe what's
going on changes things.
Could you test if the following patch affects the stability?
YAMAMOTO Mitsuharu
[EMAIL PROTECTED]
Index: src/alloc.c
===
RCS file: /sources/emacs/emacs/src/alloc.c,v
retrieving revision 1.407
diff -c -p -r1.407 alloc.c
*** src/alloc.c 21 Jan 2007 04:18:17 - 1.407
--- src/alloc.c 23 Jan 2007 07:43:15 -
*** static pthread_mutex_t alloc_mutex;
*** 131,137
do\
{ \
if (pthread_equal (pthread_self (), main_thread)) \
! sigblock (sigmask (SIGIO)); \
pthread_mutex_lock (alloc_mutex);\
} \
while (0)
--- 131,137
do\
{ \
if (pthread_equal (pthread_self (), main_thread)) \
! BLOCK_INPUT; \
pthread_mutex_lock (alloc_mutex);\
} \
while (0)
*** static pthread_mutex_t alloc_mutex;
*** 140,146
{ \
pthread_mutex_unlock (alloc_mutex); \
if (pthread_equal (pthread_self (), main_thread)) \
! sigunblock (sigmask (SIGIO)); \
} \
while (0)
--- 140,146
{ \
pthread_mutex_unlock (alloc_mutex); \
if (pthread_equal (pthread_self (), main_thread)) \
! UNBLOCK_INPUT;\
} \
while (0)
Index: src/blockinput.h
===
RCS file: /sources/emacs/emacs/src/blockinput.h,v
retrieving revision 1.21
diff -c -p -r1.21 blockinput.h
*** src/blockinput.h14 Jan 2007 03:24:37 - 1.21
--- src/blockinput.h23 Jan 2007 07:43:15 -
*** Boston, MA 02110-1301, USA. */
*** 49,55
interrupt_input_pending to a non-zero value. If that flag is set
when input becomes unblocked, UNBLOCK_INPUT will send a new SIGIO. */
! extern int interrupt_input_blocked;
/* Nonzero means an input interrupt has arrived
during the current critical section. */
--- 49,55
interrupt_input_pending to a non-zero value. If that flag is set
when input becomes unblocked, UNBLOCK_INPUT will send a new SIGIO. */
! extern volatile int interrupt_input_blocked;
/* Nonzero means an input interrupt has arrived
during the current critical section. */
Index: src/keyboard.c
===
RCS file: /sources/emacs/emacs/src/keyboard.c,v
retrieving revision 1.890
diff -c -p -r1.890 keyboard.c
*** src/keyboard.c 21 Jan 2007 04:18:15 - 1.890
--- src/keyboard.c 23 Jan 2007 07:43:16 -
*** extern int errno;
*** 90,96
/* Variables for blockinput.h: */
/* Non-zero if interrupt input is blocked right now. */
! int interrupt_input_blocked;
/* Nonzero means an input interrupt has arrived
during the current critical section. */
--- 90,96
/* Variables for blockinput.h: */
/* Non-zero if interrupt input is blocked right now. */
! volatile int interrupt_input_blocked;
/* Nonzero means an input interrupt has arrived
during the current critical section. */
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: 4 week-old pretest bugs
Chris Moore skrev: Jan Djärv [EMAIL PROTECTED] writes: By using sigblock/sigunblock we make sure that counter isn't touched, so it fixes this particular case. However, why the counter gets the wrong value is still not known. Can anyone even reproduce the bug other than me? Well, I can't. If not, I'm more than happy to run any test cases you would like me to try. I've tried debugging it in various ways myself, but the timing seems to be so touchy that any attempt to observe what's going on changes things. Great. However, I still have nothing new :-( Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: 4 week-old pretest bugs
Jan Djärv [EMAIL PROTECTED] writes: By using sigblock/sigunblock we make sure that counter isn't touched, so it fixes this particular case. However, why the counter gets the wrong value is still not known. Can anyone even reproduce the bug other than me? If not, I'm more than happy to run any test cases you would like me to try. I've tried debugging it in various ways myself, but the timing seems to be so touchy that any attempt to observe what's going on changes things. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: 4 week-old pretest bugs
Stefan Monnier skrev: it before incrementing interrupt_input_blocked in the #define for BLOCK_INPUT fixes the bug! Are you sure it fixes it? It may just hide it by slightly changing the timing. The bug occurs because revoke_input_signal is called when it should not be. Somehow the counter used by UNBLOCK/BLOCK_INPUT gets the wrong value, becoming negative. By using sigblock/sigunblock we make sure that counter isn't touched, so it fixes this particular case. However, why the counter gets the wrong value is still not known. Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: 4 week-old pretest bugs
Some, but the root cause is still unknown. It seems UNBLOCK_INPUT gets called more than BLOCK_INPUT, so the counter goes below zero and Emacs aborts (in UNBLOCK_INPUT). It is easy to see how a function could return failing to do UNBLOCK_INPUT, which would cause the opposite problem. However, it is hard to see how anything could do UNBLOCK_INPUT without BLOCK_INPUT. Perhaps an ugly control flow might bypass the BLOCK_INPUT and not bypass the corresponding UNBLOCK_INPUT. Misuse of TOTALLY_UNBLOCK_INPUT or UNBLOCK_INPUT_TO could cause this problem. UNBLOCK_INPUT_TO is used in unwind_to_catch. Maybe there is a way you can arrange to record how recently unwind_to_catch was last called. If you create a counter, and have code that gets called fairly often increment it, you could make unwind_to_catch record the counter values of the last 10 times it was called. Maybe that would enable you to tell whether unwind_to_catch plays a role in this bug. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: 4 week-old pretest bugs
it before incrementing interrupt_input_blocked in the #define for BLOCK_INPUT fixes the bug! Are you sure it fixes it? It may just hide it by slightly changing the timing. Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: 4 week-old pretest bugs
Richard Stallman skrev: * running the same build on the same debian sid machine under KDE when you run it under KDE, is that the GTK build of Emacs? It's the same build in all cases. The same binary files. I make a .deb package from the results of the build and install that same package on both machines, and run that same package under the various desktop environments. So in all cases it's using GTK. How bizarre. I don't know if you saw the silly patch for the problem which I posted earlier today, but adding a static integer variable and incrementing it before incrementing interrupt_input_blocked in the #define for BLOCK_INPUT fixes the bug! This suggests to me that it has something to do with multithreading. I have a vague memory that GTK uses multithreading. It is the file dialog in Gtk+ that uses several threads. Jan, do you get any ideas from this? Some, but the root cause is still unknown. It seems UNBLOCK_INPUT gets called more than BLOCK_INPUT, so the counter goes below zero and Emacs aborts (in UNBLOCK_INPUT). Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: 4 week-old pretest bugs
Jan Djärv [EMAIL PROTECTED] writes:
It is probably very timing related. A small change changes the timing. Can
you try the attachet patch?
That fixes the problem.
I ran the patched program 4 times, each time clicking the first icon a
lot of times to see if I could provoke a crash and I couldn't.
The first time I clicked the icon in the first run, however, I saw a
CRITICAL message in the terminal I ran it from:
[EMAIL PROTECTED]:~/programs/emacs$ emacs -Q
(emacs:16263): libgnomevfs-CRITICAL **: gnome_vfs_get_uri_from_local_path:
assertion `g_path_is_absolute (local_full_path)' failed
[EMAIL PROTECTED]:~/programs/emacs$ emacs -Q
[EMAIL PROTECTED]:~/programs/emacs$ emacs -Q
[EMAIL PROTECTED]:~/programs/emacs$ emacs -Q
[EMAIL PROTECTED]:~/programs/emacs$
This may of course be completely irrelevant.
Chris.
Index: alloc.c
*** alloc.c.~1.405.~ 2007-01-01 19:19:05.0 +0100
--- alloc.c 2007-01-11 08:44:47.0 +0100
***
*** 130,137
#define BLOCK_INPUT_ALLOC \
do\
{ \
! if (pthread_self () == main_thread) \
! BLOCK_INPUT;\
pthread_mutex_lock (alloc_mutex);\
} \
while (0)
--- 130,137
#define BLOCK_INPUT_ALLOC \
do\
{ \
! if (pthread_equal (pthread_self (), main_thread)) \
! sigblock (sigmask (SIGIO)); \
pthread_mutex_lock (alloc_mutex);\
} \
while (0)
***
*** 139,146
do\
{ \
pthread_mutex_unlock (alloc_mutex); \
! if (pthread_self () == main_thread) \
! UNBLOCK_INPUT; \
} \
while (0)
--- 139,146
do\
{ \
pthread_mutex_unlock (alloc_mutex); \
! if (pthread_equal (pthread_self (), main_thread)) \
! sigunblock (sigmask (SIGIO)); \
} \
while (0)
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: 4 week-old pretest bugs
Chris Moore skrev: Jan Djärv [EMAIL PROTECTED] writes: It is probably very timing related. A small change changes the timing. Can you try the attachet patch? That fixes the problem. Good. I ran the patched program 4 times, each time clicking the first icon a lot of times to see if I could provoke a crash and I couldn't. The first time I clicked the icon in the first run, however, I saw a CRITICAL message in the terminal I ran it from: [EMAIL PROTECTED]:~/programs/emacs$ emacs -Q (emacs:16263): libgnomevfs-CRITICAL **: gnome_vfs_get_uri_from_local_path: assertion `g_path_is_absolute (local_full_path)' failed [EMAIL PROTECTED]:~/programs/emacs$ emacs -Q [EMAIL PROTECTED]:~/programs/emacs$ emacs -Q [EMAIL PROTECTED]:~/programs/emacs$ emacs -Q [EMAIL PROTECTED]:~/programs/emacs$ This may of course be completely irrelevant. The Gtk+ file dialog wants only absolute file names. Maybe tehre is some case where we set the default file/directory to something non-absolute? I'll investigate. Thanks, Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: 4 week-old pretest bugs
Jan Djärv [EMAIL PROTECTED] writes: The Gtk+ file dialog wants only absolute file names. Maybe tehre is some case where we set the default file/directory to something non-absolute? I'll investigate. I did exactly the same 4 times in a row, and only saw the message the first time. That may well have been the very first time the GTK file dialog was displayed since I booted as I never use it. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: 4 week-old pretest bugs
Some, but the root cause is still unknown. It seems UNBLOCK_INPUT gets called more than BLOCK_INPUT, so the counter goes below zero and Emacs aborts (in UNBLOCK_INPUT). It is easy to see how a function could return failing to do UNBLOCK_INPUT, which would cause the opposite problem. However, it is hard to see how anything could do UNBLOCK_INPUT without BLOCK_INPUT. Perhaps an ugly control flow might bypass the BLOCK_INPUT and not bypass the corresponding UNBLOCK_INPUT. Misuse of TOTALLY_UNBLOCK_INPUT or UNBLOCK_INPUT_TO could cause this problem. UNBLOCK_INPUT_TO is used in unwind_to_catch. Maybe there is a way you can arrange to record how recently unwind_to_catch was last called. If you create a counter, and have code that gets called fairly often increment it, you could make unwind_to_catch record the counter values of the last 10 times it was called. Maybe that would enable you to tell whether unwind_to_catch plays a role in this bug. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: 4 week-old pretest bugs
Jan Djärv [EMAIL PROTECTED] writes: Thanks. Somehow the thread detection thingy isn't working correctly. While I try to figure this out, please try the patch suggested by YAMAMOTO Mitsuharu. That patch didn't appear to make any difference, but I've found one that fixes the bug for me. I have no idea why it works, but it does really seem to: --- src/blockinput.h2007-01-10 18:22:43.0 +0100 +++ src/new/blockinput.h2007-01-10 18:18:18.0 +0100 @@ -61,8 +61,10 @@ extern int pending_atimers; +static int mytmp; + /* Begin critical section. */ -#define BLOCK_INPUT (interrupt_input_blocked++) +#define BLOCK_INPUT (mytmp++, interrupt_input_blocked++) /* End critical section. I suppose this must be indicitive of some kind of race condition, since the mytmp++ doesn't do anything but delay the increment of interrupt_input_blocked by a very short amount of time. Chris. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: 4 week-old pretest bugs
* running the same build on the same debian sid machine under KDE * running the same build on the same debian sid machine with different GTK theme (tried Amaranth, Crux and Simple - all show the crash) So it's something specific to GNOME on this laptop. Is it a matter of running under GNOME, or a matter of building with GTK? In other words, when you run it under KDE, is that the GTK build of Emacs? Unfortunately, the comparison between the two machines is not very conclusive because so many things could be different between them. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: 4 week-old pretest bugs
Richard Stallman [EMAIL PROTECTED] writes: * running the same build on the same debian sid machine under KDE when you run it under KDE, is that the GTK build of Emacs? It's the same build in all cases. The same binary files. I make a .deb package from the results of the build and install that same package on both machines, and run that same package under the various desktop environments. So in all cases it's using GTK. Unfortunately, the comparison between the two machines is not very conclusive because so many things could be different between them. I don't know if you saw the silly patch for the problem which I posted earlier today, but adding a static integer variable and incrementing it before incrementing interrupt_input_blocked in the #define for BLOCK_INPUT fixes the bug! I arrived at that fix through a process of trial and error, not through any understand at all of what's going on. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: 4 week-old pretest bugs
* running the same build on the same debian sid machine under KDE when you run it under KDE, is that the GTK build of Emacs? It's the same build in all cases. The same binary files. I make a .deb package from the results of the build and install that same package on both machines, and run that same package under the various desktop environments. So in all cases it's using GTK. How bizarre. I don't know if you saw the silly patch for the problem which I posted earlier today, but adding a static integer variable and incrementing it before incrementing interrupt_input_blocked in the #define for BLOCK_INPUT fixes the bug! This suggests to me that it has something to do with multithreading. I have a vague memory that GTK uses multithreading. Jan, do you get any ideas from this? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: 4 week-old pretest bugs
Chris Moore skrev:
Richard Stallman [EMAIL PROTECTED] writes:
* running the same build on the same debian sid machine under KDE
when you run it under KDE, is that the GTK build of Emacs?
It's the same build in all cases. The same binary files. I make a
.deb package from the results of the build and install that same
package on both machines, and run that same package under the various
desktop environments. So in all cases it's using GTK.
Unfortunately, the comparison between the two machines is not very
conclusive because so many things could be different between them.
I don't know if you saw the silly patch for the problem which I posted
earlier today, but adding a static integer variable and incrementing
it before incrementing interrupt_input_blocked in the #define for
BLOCK_INPUT fixes the bug!
I arrived at that fix through a process of trial and error, not
through any understand at all of what's going on.
It is probably very timing related. A small change changes the timing. Can
you try the attachet patch?
Jan D.
Index: alloc.c
*** alloc.c.~1.405.~ 2007-01-01 19:19:05.0 +0100
--- alloc.c 2007-01-11 08:44:47.0 +0100
***
*** 130,137
#define BLOCK_INPUT_ALLOC \
do\
{ \
! if (pthread_self () == main_thread) \
! BLOCK_INPUT;\
pthread_mutex_lock (alloc_mutex); \
} \
while (0)
--- 130,137
#define BLOCK_INPUT_ALLOC \
do\
{ \
! if (pthread_equal (pthread_self (), main_thread)) \
! sigblock (sigmask (SIGIO)); \
pthread_mutex_lock (alloc_mutex);\
} \
while (0)
***
*** 139,146
do\
{ \
pthread_mutex_unlock (alloc_mutex); \
! if (pthread_self () == main_thread) \
! UNBLOCK_INPUT;\
} \
while (0)
--- 139,146
do\
{ \
pthread_mutex_unlock (alloc_mutex); \
! if (pthread_equal (pthread_self (), main_thread)) \
! sigunblock (sigmask (SIGIO)); \
} \
while (0)
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: 4 week-old pretest bugs
YAMAMOTO Mitsuharu [EMAIL PROTECTED] writes: Could you try to see if the following patch changes the situation? It took 3 or 4 runs before I got the abort() to happen, but it still happened. Told me something about a corrupted dwarf, which made me smile. Here's the new gdb output: [EMAIL PROTECTED]:~/programs/emacs/src$ gdb ./emacs GNU gdb 6.5-debian Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i486-linux-gnu...Using host libthread_db library /lib/tls/libthread_db.so.1. DISPLAY = :0.0 TERM = dumb Breakpoint 1 at 0x80f4106: file emacs.c, line 431. Breakpoint 2 at 0x810d2e9: file sysdep.c, line 1385. (gdb) run -Q Starting program: /home/chris/programs/emacs/src/emacs -Q Failed to read a valid object file image from memory. [Thread debugging using libthread_db enabled] [New Thread -1219807008 (LWP 23559)] [Switching to Thread -1219807008 (LWP 23559)] Breakpoint 3 at 0x80c93f6: file xterm.c, line 7848. [New Thread -1230275664 (LWP 23562)] [New Thread -1233417296 (LWP 23563)] Breakpoint 1, abort () at emacs.c:431 431 kill (getpid (), SIGABRT); (gdb) where #0 abort () at emacs.c:431 #1 0x08148395 in emacs_blocked_free (ptr=0xb69005c8, ptr2=0xb78dbf21) at alloc.c:1223 #2 0xb75e08f5 in free () from /lib/tls/libc.so.6 #3 0xb78dbf21 in g_free () from /usr/lib/libglib-2.0.so.0 #4 0xb7da819d in gtk_rc_get_style () from /usr/lib/libgtk-x11-2.0.so.0 #5 0xb7e608e8 in gtk_widget_set_usize () from /usr/lib/libgtk-x11-2.0.so.0 #6 0xb7e6120d in gtk_widget_set_name () from /usr/lib/libgtk-x11-2.0.so.0 #7 0x080f0eae in xg_get_file_name (f=0x8603ac8, prompt=0x82bc04d Find file: , default_filename=0x87be7a4 /home/chris/programs/emacs/src/, mustmatch_p=0, only_dir_p=0) at gtkutil.c:1551 #8 0x080d1c10 in Fx_file_dialog (prompt=136174920, dir=139876723, default_filename=140520968, mustmatch=137468105, only_dir_p=137468105) at xfns.c:5573 #9 0x08123df8 in Fread_file_name (prompt=136174923, dir=value optimized out, default_filename=value optimized out, mustmatch=137468105, initial=137468105, predicate=value optimized out) at fileio.c:6401 #10 0x0815bc0a in Ffuncall (nargs=5, args=0xbfff00c0) at eval.c:3016 #11 0x0818642a in Fbyte_code (bytestr=136174603, vector=136174620, maxdepth=40) at bytecode.c:679 #12 0x0815b5e4 in funcall_lambda (fun=136174564, nargs=2, arg_vector=0xbfff0190) at eval.c:3184 #13 0x0815b7f7 in apply_lambda (fun=136174564, args=136174917, eval_flag=1) at eval.c:3108 #14 0x0815aeb8 in Feval (form=136174909) at eval.c:2370 #15 0x08158aa6 in Fcall_interactively (function=137779033, record_flag=137468105, keys=137508620) at callint.c:378 #16 0x080f8cd3 in Fcommand_execute (cmd=137779033, record_flag=dwarf2_read_address: Corrupted DWARF expression. ) at keyboard.c:10013 #17 0x081046da in command_loop_1 () at keyboard.c:1873 #18 0x0815a61b in internal_condition_case (bfun=0x8104360 command_loop_1, handlers=137512761, hfun=0x80fed00 cmd_error) at eval.c:1481 #19 0x080fe0de in command_loop_2 () at keyboard.c:1329 #20 0x0815a6dc in internal_catch (tag=137506745, func=0x80fe0b0 command_loop_2, arg=137468105) at eval.c:1222 #21 0x080feb4e in command_loop () at keyboard.c:1308 #22 0x080feed8 in recursive_edit_1 () at keyboard.c:1006 #23 0x080fefc6 in Frecursive_edit () at keyboard.c:1067 #24 0x080f4eb2 in main (argc=Cannot access memory at address 0x0 ) at emacs.c:1761 Lisp Backtrace: read-file-name (0x81ddd4b) find-file-read-args (0x81ddd4b) call-interactively (0x8365759) (gdb) info threads 3 Thread -1233417296 (LWP 23563) 0xb6fc655b in gnome_vfs_xfer_uri () from /usr/lib/libgnomevfs-2.so.0 2 Thread -1230275664 (LWP 23562) 0xb763ce49 in poll () from /lib/tls/libc.so.6 * 1 Thread -1219807008 (LWP 23559) abort () at emacs.c:431 (gdb) thr 1 [Switching to thread 1 (Thread -1219807008 (LWP 23559))]#0 abort () at emacs.c:431 431 kill (getpid (), SIGABRT); (gdb) bt #0 abort () at emacs.c:431 #1 0x08148395 in emacs_blocked_free (ptr=0xb69005c8, ptr2=0xb78dbf21) at alloc.c:1223 #2 0xb75e08f5 in free () from /lib/tls/libc.so.6 #3 0xb78dbf21 in g_free () from /usr/lib/libglib-2.0.so.0 #4 0xb7da819d in gtk_rc_get_style () from /usr/lib/libgtk-x11-2.0.so.0 #5 0xb7e608e8 in gtk_widget_set_usize () from /usr/lib/libgtk-x11-2.0.so.0 #6 0xb7e6120d in gtk_widget_set_name () from /usr/lib/libgtk-x11-2.0.so.0 #7 0x080f0eae in xg_get_file_name (f=0x8603ac8, prompt=0x82bc04d Find file: , default_filename=0x87be7a4 /home/chris/programs/emacs/src/, mustmatch_p=0, only_dir_p=0) at gtkutil.c:1551 #8 0x080d1c10 in Fx_file_dialog (prompt=136174920, dir=139876723, default_filename=140520968,
Re: 4 week-old pretest bugs
Chris Moore [EMAIL PROTECTED] writes: It took 3 or 4 runs before I got the abort() to happen, but it still happened. Told me something about a corrupted dwarf, which made me smile. I tried a few experiments: no crash - works fine: - * running the same build on the same debian sid machine under KDE * running the same build on a different debian sid machine under GNOME * running the same build on a different debian sid machine under XFCE4 abort()s: * running the same build on the same debian sid machine with different GTK theme (tried Amaranth, Crux and Simple - all show the crash) So it's something specific to GNOME on this laptop. The laptop where it crashes has a dual core processor: [EMAIL PROTECTED]:~$ grep model /proc/cpuinfo model : 14 model name: Genuine Intel(R) CPU T2500 @ 2.00GHz model : 14 model name: Genuine Intel(R) CPU T2500 @ 2.00GHz The one where it doesn't is a 5 year old (single core) P4: (debian) [EMAIL PROTECTED]:~$ grep model /proc/cpuinfo model : 2 model name: Intel(R) Pentium(R) 4 CPU 2.20GHz The machine where it crashes is the same machine where I build Emacs (using the -j 2 flag to use both cores to build). ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: 4 week-old pretest bugs
Jan Djärv [EMAIL PROTECTED] writes: Can you run emacs in gdb and do a backtrace when this (Abort) happens? Sure: Breakpoint 1, abort () at emacs.c:431 431 kill (getpid (), SIGABRT); (gdb) where #0 abort () at emacs.c:431 #1 0x08147f7b in emacs_blocked_malloc (size=16, ptr=0xb793c0b6) at alloc.c:1268 #2 0xb7642c05 in malloc () from /lib/tls/libc.so.6 #3 0xb793c0b6 in g_malloc () from /usr/lib/libglib-2.0.so.0 #4 0xb7e7dbcc in _gtk_tree_data_list_header_new () from /usr/lib/libgtk-x11-2.0.so.0 #5 0xb7dc9b77 in gtk_list_store_clear () from /usr/lib/libgtk-x11-2.0.so.0 #6 0xb7dc9e6f in gtk_list_store_new () from /usr/lib/libgtk-x11-2.0.so.0 #7 0xb7d6ddf7 in _gtk_file_chooser_entry_set_base_folder () from /usr/lib/libgtk-x11-2.0.so.0 #8 0xb79c4057 in g_source_set_closure () from /usr/lib/libgobject-2.0.so.0 #9 0xb79ac98b in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #10 0xb79c4000 in g_source_set_closure () from /usr/lib/libgobject-2.0.so.0 #11 0xb7932da1 in g_source_is_destroyed () from /usr/lib/libglib-2.0.so.0 #12 0xb7934b21 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #13 0xb7937b96 in g_main_context_check () from /usr/lib/libglib-2.0.so.0 #14 0xb7938117 in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0 #15 0xb7dcc0e5 in gtk_main_iteration () from /usr/lib/libgtk-x11-2.0.so.0 #16 0x080c90ae in XTread_socket (sd=0, expected=1, hold_quit=0xbfc06b04) at xterm.c:7078 #17 0x080fb72d in read_avail_input (expected=1) at keyboard.c:6823 #18 0x080fb92a in handle_async_input () at keyboard.c:6969 #19 0x08148095 in emacs_blocked_free (ptr=0xb6005ba0, ptr2=0xb793bf21) at alloc.c:1223 #20 0xb76408f5 in free () from /lib/tls/libc.so.6 #21 0xb793bf21 in g_free () from /usr/lib/libglib-2.0.so.0 #22 0xb701caac in gnome_vfs_make_uri_canonical () from /usr/lib/libgnomevfs-2.so.0 #23 0xb706957f in fs_module_init () from /usr/lib/gtk-2.0/2.4.0/filesystems/libgnome-vfs.so #24 0xb7d836b4 in gtk_file_system_uri_to_path () from /usr/lib/libgtk-x11-2.0.so.0 #25 0xb7069169 in fs_module_init () from /usr/lib/gtk-2.0/2.4.0/filesystems/libgnome-vfs.so #26 0xb7d83416 in gtk_file_system_list_bookmarks () from /usr/lib/libgtk-x11-2.0.so.0 #27 0xb7d73fb5 in _gtk_file_chooser_default_new () from /usr/lib/libgtk-x11-2.0.so.0 #28 0xb7d74201 in _gtk_file_chooser_default_new () from /usr/lib/libgtk-x11-2.0.so.0 #29 0xb7d742df in _gtk_file_chooser_default_new () from /usr/lib/libgtk-x11-2.0.so.0 #30 0xb79b9e1b in g_cclosure_marshal_VOID__VOID () from /usr/lib/libgobject-2.0.so.0 #31 0xb79aaf49 in g_value_set_boxed () from /usr/lib/libgobject-2.0.so.0 #32 0xb79aca7c in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #33 0xb79bd3b8 in g_signal_chain_from_overridden () from /usr/lib/libgobject-2.0.so.0 #34 0xb79be429 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #35 0xb79be5d9 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #36 0xb7ec1eef in gtk_widget_map () from /usr/lib/libgtk-x11-2.0.so.0 #37 0xb7d3f5a5 in gtk_container_child_type () from /usr/lib/libgtk-x11-2.0.so.0 #38 0xb7d020d0 in gtk_box_pack_start_defaults () from /usr/lib/libgtk-x11-2.0.so.0 #39 0xb7d3cecc in gtk_container_forall () from /usr/lib/libgtk-x11-2.0.so.0 #40 0xb7d3f559 in gtk_container_child_type () from /usr/lib/libgtk-x11-2.0.so.0 #41 0xb79b9e1b in g_cclosure_marshal_VOID__VOID () from /usr/lib/libgobject-2.0.so.0 #42 0xb79aaf49 in g_value_set_boxed () from /usr/lib/libgobject-2.0.so.0 #43 0xb79aca7c in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #44 0xb79bd3b8 in g_signal_chain_from_overridden () from /usr/lib/libgobject-2.0.so.0 #45 0xb79be429 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #46 0xb79be5d9 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #47 0xb7ec1eef in gtk_widget_map () from /usr/lib/libgtk-x11-2.0.so.0 #48 0xb7d6c933 in gtk_file_chooser_dialog_new () from /usr/lib/libgtk-x11-2.0.so.0 #49 0xb79b9e1b in g_cclosure_marshal_VOID__VOID () #50 0xb79aaf49 in g_value_set_boxed () from /usr/lib/libgobject-2.0.so.0 #51 0xb79ac98b in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #52 0xb79bd3b8 in g_signal_chain_from_overridden () from /usr/lib/libgobject-2.0.so.0 #53 0xb79be429 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #54 0xb79be5d9 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #55 0xb7ec1eef in gtk_widget_map () from /usr/lib/libgtk-x11-2.0.so.0 #56 0xb7ed07c0 in gtk_window_new () from /usr/lib/libgtk-x11-2.0.so.0 #57 0xb79b9e1b in g_cclosure_marshal_VOID__VOID () from /usr/lib/libgobject-2.0.so.0 #58 0xb79aaf49 in g_value_set_boxed () from /usr/lib/libgobject-2.0.so.0 #59 0xb79ac98b in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #60 0xb79bd3b8 in g_signal_chain_from_overridden () from /usr/lib/libgobject-2.0.so.0 #61 0xb79be429 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #62 0xb79be5d9 in g_signal_emit () from
Re: 4 week-old pretest bugs
Chris Moore skrev: Jan Djärv [EMAIL PROTECTED] writes: Can you run emacs in gdb and do a backtrace when this (Abort) happens? Sure: Thanks for the info. I've checked in a change, can you test it? Jan D. Breakpoint 1, abort () at emacs.c:431 431 kill (getpid (), SIGABRT); (gdb) where #0 abort () at emacs.c:431 #1 0x08147f7b in emacs_blocked_malloc (size=16, ptr=0xb793c0b6) at alloc.c:1268 #2 0xb7642c05 in malloc () from /lib/tls/libc.so.6 #3 0xb793c0b6 in g_malloc () from /usr/lib/libglib-2.0.so.0 #4 0xb7e7dbcc in _gtk_tree_data_list_header_new () from /usr/lib/libgtk-x11-2.0.so.0 #5 0xb7dc9b77 in gtk_list_store_clear () from /usr/lib/libgtk-x11-2.0.so.0 #6 0xb7dc9e6f in gtk_list_store_new () from /usr/lib/libgtk-x11-2.0.so.0 #7 0xb7d6ddf7 in _gtk_file_chooser_entry_set_base_folder () from /usr/lib/libgtk-x11-2.0.so.0 #8 0xb79c4057 in g_source_set_closure () from /usr/lib/libgobject-2.0.so.0 #9 0xb79ac98b in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #10 0xb79c4000 in g_source_set_closure () from /usr/lib/libgobject-2.0.so.0 #11 0xb7932da1 in g_source_is_destroyed () from /usr/lib/libglib-2.0.so.0 #12 0xb7934b21 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #13 0xb7937b96 in g_main_context_check () from /usr/lib/libglib-2.0.so.0 #14 0xb7938117 in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0 #15 0xb7dcc0e5 in gtk_main_iteration () from /usr/lib/libgtk-x11-2.0.so.0 #16 0x080c90ae in XTread_socket (sd=0, expected=1, hold_quit=0xbfc06b04) at xterm.c:7078 #17 0x080fb72d in read_avail_input (expected=1) at keyboard.c:6823 #18 0x080fb92a in handle_async_input () at keyboard.c:6969 #19 0x08148095 in emacs_blocked_free (ptr=0xb6005ba0, ptr2=0xb793bf21) at alloc.c:1223 #20 0xb76408f5 in free () from /lib/tls/libc.so.6 #21 0xb793bf21 in g_free () from /usr/lib/libglib-2.0.so.0 #22 0xb701caac in gnome_vfs_make_uri_canonical () from /usr/lib/libgnomevfs-2.so.0 #23 0xb706957f in fs_module_init () from /usr/lib/gtk-2.0/2.4.0/filesystems/libgnome-vfs.so #24 0xb7d836b4 in gtk_file_system_uri_to_path () from /usr/lib/libgtk-x11-2.0.so.0 #25 0xb7069169 in fs_module_init () from /usr/lib/gtk-2.0/2.4.0/filesystems/libgnome-vfs.so #26 0xb7d83416 in gtk_file_system_list_bookmarks () from /usr/lib/libgtk-x11-2.0.so.0 #27 0xb7d73fb5 in _gtk_file_chooser_default_new () from /usr/lib/libgtk-x11-2.0.so.0 #28 0xb7d74201 in _gtk_file_chooser_default_new () from /usr/lib/libgtk-x11-2.0.so.0 #29 0xb7d742df in _gtk_file_chooser_default_new () from /usr/lib/libgtk-x11-2.0.so.0 #30 0xb79b9e1b in g_cclosure_marshal_VOID__VOID () from /usr/lib/libgobject-2.0.so.0 #31 0xb79aaf49 in g_value_set_boxed () from /usr/lib/libgobject-2.0.so.0 #32 0xb79aca7c in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #33 0xb79bd3b8 in g_signal_chain_from_overridden () from /usr/lib/libgobject-2.0.so.0 #34 0xb79be429 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #35 0xb79be5d9 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #36 0xb7ec1eef in gtk_widget_map () from /usr/lib/libgtk-x11-2.0.so.0 #37 0xb7d3f5a5 in gtk_container_child_type () from /usr/lib/libgtk-x11-2.0.so.0 #38 0xb7d020d0 in gtk_box_pack_start_defaults () from /usr/lib/libgtk-x11-2.0.so.0 #39 0xb7d3cecc in gtk_container_forall () from /usr/lib/libgtk-x11-2.0.so.0 #40 0xb7d3f559 in gtk_container_child_type () from /usr/lib/libgtk-x11-2.0.so.0 #41 0xb79b9e1b in g_cclosure_marshal_VOID__VOID () from /usr/lib/libgobject-2.0.so.0 #42 0xb79aaf49 in g_value_set_boxed () from /usr/lib/libgobject-2.0.so.0 #43 0xb79aca7c in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #44 0xb79bd3b8 in g_signal_chain_from_overridden () from /usr/lib/libgobject-2.0.so.0 #45 0xb79be429 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #46 0xb79be5d9 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #47 0xb7ec1eef in gtk_widget_map () from /usr/lib/libgtk-x11-2.0.so.0 #48 0xb7d6c933 in gtk_file_chooser_dialog_new () from /usr/lib/libgtk-x11-2.0.so.0 #49 0xb79b9e1b in g_cclosure_marshal_VOID__VOID () #50 0xb79aaf49 in g_value_set_boxed () from /usr/lib/libgobject-2.0.so.0 #51 0xb79ac98b in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #52 0xb79bd3b8 in g_signal_chain_from_overridden () from /usr/lib/libgobject-2.0.so.0 #53 0xb79be429 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #54 0xb79be5d9 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #55 0xb7ec1eef in gtk_widget_map () from /usr/lib/libgtk-x11-2.0.so.0 #56 0xb7ed07c0 in gtk_window_new () from /usr/lib/libgtk-x11-2.0.so.0 #57 0xb79b9e1b in g_cclosure_marshal_VOID__VOID () from /usr/lib/libgobject-2.0.so.0 #58 0xb79aaf49 in g_value_set_boxed () from /usr/lib/libgobject-2.0.so.0 #59 0xb79ac98b in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #60 0xb79bd3b8
Re: 4 week-old pretest bugs
Chris Moore [EMAIL PROTECTED] writes: Incidentally, which file(s) did you edit? I had a look at some Changelog files but can't see anything that looks relevant. Sorry, ignore that question. I was thinking that xterm.c was for Emacsen running inside a xterm... ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: 4 week-old pretest bugs
Could you try to see if the following patch changes the situation?
YAMAMOTO Mitsuharu
[EMAIL PROTECTED]
Index: src/alloc.c
===
RCS file: /cvsroot/emacs/emacs/src/alloc.c,v
retrieving revision 1.405
diff -c -p -r1.405 alloc.c
*** src/alloc.c 13 Nov 2006 08:20:28 - 1.405
--- src/alloc.c 9 Jan 2007 04:30:08 -
*** extern __malloc_size_t __malloc_extra_bl
*** 127,147
static pthread_mutex_t alloc_mutex;
! #define BLOCK_INPUT_ALLOC \
! do\
! { \
! if (pthread_self () == main_thread) \
! BLOCK_INPUT;\
! pthread_mutex_lock (alloc_mutex); \
! } \
while (0)
! #define UNBLOCK_INPUT_ALLOC \
! do\
! { \
! pthread_mutex_unlock (alloc_mutex);\
! if (pthread_self () == main_thread) \
! UNBLOCK_INPUT; \
! } \
while (0)
#else /* SYSTEM_MALLOC || not HAVE_GTK_AND_PTHREAD */
--- 127,147
static pthread_mutex_t alloc_mutex;
! #define BLOCK_INPUT_ALLOC \
! do \
! { \
! if (pthread_equal (pthread_self (), main_thread)) \
! BLOCK_INPUT;\
! pthread_mutex_lock (alloc_mutex); \
! } \
while (0)
! #define UNBLOCK_INPUT_ALLOC \
! do \
! { \
! pthread_mutex_unlock (alloc_mutex);\
! if (pthread_equal (pthread_self (), main_thread)) \
! UNBLOCK_INPUT; \
! } \
while (0)
#else /* SYSTEM_MALLOC || not HAVE_GTK_AND_PTHREAD */
Index: src/syssignal.h
===
RCS file: /cvsroot/emacs/emacs/src/syssignal.h,v
retrieving revision 1.43
diff -c -p -r1.43 syssignal.h
*** src/syssignal.h 6 Feb 2006 15:23:21 - 1.43
--- src/syssignal.h 9 Jan 2007 04:30:08 -
*** char *strsignal ();
*** 210,216
#ifdef HAVE_GTK_AND_PTHREAD
#define SIGNAL_THREAD_CHECK(signo) \
do { \
! if (pthread_self () != main_thread) \
{ \
/* POSIX says any thread can receive the signal. On GNU/Linux \
that is not true, but for other systems (FreeBSD at least) \
--- 210,216
#ifdef HAVE_GTK_AND_PTHREAD
#define SIGNAL_THREAD_CHECK(signo) \
do { \
! if (!pthread_equal (pthread_self (), main_thread))
\
{ \
/* POSIX says any thread can receive the signal. On GNU/Linux \
that is not true, but for other systems (FreeBSD at least) \
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: 4 week-old pretest bugs
Chris Moore skrev: In my original report I mentioned that when I click the first icon, one of three things happens: 1) Emacs aborts 2) I see Xlib: unexpected async reply 3) It works as expected Your change seems to have eliminated number 3 in the above list. It now aborts almost every time I click the first icon, and about 1 in 4 times displays the Xlib error message. Well, it is progress of some sort... Incidentally, which file(s) did you edit? I had a look at some Changelog files but can't see anything that looks relevant. I simply initialized some variables in keyboard.c (interrupt_input_blocked and interrupt_input_pending) which wasn't explicitly initialized. Here's new output from gdb: Thanks. Somehow the thread detection thingy isn't working correctly. While I try to figure this out, please try the patch suggested by YAMAMOTO Mitsuharu. Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: 4 week-old pretest bugs
I thought I had been pretty precise, but here's a character-by-character (from C-h l) demonstration of how to open a customize window, search for the 'state' button, hit return and then f1 on it: I fixed this. Thanks. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
4 week-old pretest bugs
I've been offline for a week or so, and still have very limited net connectivity, but since I've been offline I've found a few Emacs bugs which I thought I should report. These are from a CVS Emacs 19.22.92 (?) from 22nd or 23rd December, built on GNU/Linux on an Intel 686 system. These 4 bugs may have been addressed in the last week; I'm unable to check the current state of the repository, but anyway: 1. I had a crash after trying the first icon in the gtk toolbar for the first time. I used it to find a new file, then typed C-x C-f to check which directory it had opened it in. Emacs hung at that point without displaying the directory. Here's where: A program is being debugged already. Kill it? (y or n) n Program not killed. (gdb) where #0 0xb76aad51 in ?? () #1 0x0818ba76 in wait_reading_process_output (time_limit=0, microsecs=0, read_kbd=-1, do_display=1, wait_for_cell=137459913, wait_proc=0x0, just_wait_proc=0) at process.c:4719 #2 0x080fed51 in read_char (commandflag=1, nmaps=3, maps=0xbfb78780, prev_event=137459913, used_mouse_menu=0xbfb78828, end_time=0x0) at keyboard.c:4016 #3 0x08101532 in read_key_sequence (keybuf=0xbfb788d4, bufsize=30, prompt=137459913, dont_downcase_last=0, can_return_switch_frame=1, fix_current_buffer=1) at keyboard.c:9115 #4 0x08102fe5 in command_loop_1 () at keyboard.c:1618 #5 0x08158cfb in internal_condition_case (bfun=0x8102e50 command_loop_1, handlers=137504569, hfun=0x80fd7f0 cmd_error) at eval.c:1481 #6 0x080fcbce in command_loop_2 () at keyboard.c:1329 #7 0x08158dbc in internal_catch (tag=137498553, func=0x80fcba0 command_loop_2, arg=137459913) at eval.c:1222 #8 0x080fd63e in command_loop () at keyboard.c:1308 #9 0x080fd9c8 in recursive_edit_1 () at keyboard.c:1006 #10 0x080fdab6 in Frecursive_edit () at keyboard.c:1067 #11 0x080f3a32 in main (argc=Cannot access memory at address 0x1d ) at emacs.c:1761 (gdb) q 2. running 'emacs -Q' and then clicking the first gtk icon sometimes causes a crash: Fatal error (6)Aborted other times it causes this to be printed in the starting terminal, leaving Emacs hung up: Xlib: unexpected async reply (sequence 0x11b5)! (emacs:19157): Gdk-CRITICAL **: gdk_window_set_geometry_hints: assertion `GDK_IS_WINDOW (window)' failed (emacs:19157): Gdk-CRITICAL **: gdk_window_move_resize: assertion `GDK_IS_WINDOW (window)' failed other times it just displays the 'find file' dialog as it should. 3. hitting RET on the 'state' button in a customise window prompts for a character. hitting f1 causes a lisp error: Debugger entered--Lisp error: (wrong-type-argument stringp [f1]) string-to-char([f1]) (setq value (lookup-key overriding-terminal-local-map keys t) char (while (not (or ... ...)) (setq unread-command-events (cons 32 unre (let ((cursor-in-echo-area t) keys (char 0) (arg 1)) (while (not .. (let ((buf ...)) (fit-window-to-buffer (display-buffer buf)) (let ( (save-window-excursion (let (...) (fit-window-to-buffer ...) (let . (let* ((overriding-terminal-local-map ...) (next-digit 48) map choi (cond ((and ... event ...) (x-popup-menu event ...)) ((or widget-me widget-choose(Operation on Pop Up Windows (Set for Current Sessi 4. My backup-directory-alist's value is ((. . Backup)) In the past this has resulted in backups being made in a subdirectory called 'Backup' of the edited file's directory. I'm seeing backup files like this in ~/tmp/Backup/: -rw-r--r-- 1 chris chris3 2006-12-22 16:01 !home!chris!tmp!file.txt.~1~ whereas previous the backup file would be simply called file.txt.~1~ The docstring for backup-directory-alist tells me: DIRECTORY may be relative or absolute. If it is absolute, so that all matching files are backed up into the same directory, the file names in this directory will be the full name of the file backed up with all directory separators changed to `!' to prevent clashes. my DIRECTORY is Backup, which is relative, and yet it's being treated as if it's absolute, due to the (setq backup-directory (expand-file-name backup-directory (file-name-directory file))) call in make-backup-file-name-1 I can't currently see the CVS repository to examine out recent changes, but checking lisp/ChangeLog suggests that this change may be the one which broke this: 2006-12-17 Richard Stallman [EMAIL PROTECTED] * files.el (make-backup-file-name-1): Expand backup-directory explicitly. Fix: --- programs/emacs/lisp/files.el2006-12-22 03:19:57.0 +0100 +++ emacs/files.el 2006-12-29 13:15:46.0 +0100 @@ -3227,11
Re: 4 week-old pretest bugs
I will fix bug number 4. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: 4 week-old pretest bugs
3. hitting RET on the 'state' button in a customise window prompts for a character. hitting f1 causes a lisp error: Please provide a precise, self-contained test case for this. Please read the Bugs section in the Emacs manual, which provides guidelines on how to write a bug report to give us the necessary information so we can fix the bug. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
