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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
* 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
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
* 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
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
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
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
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)
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 (),
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...
Could you try to see if the following patch changes the situation?
YAMAMOTO Mitsuharu
[EMAIL PROTECTED]
Index: src/alloc.c
===
RCS file:
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 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.
___
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
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
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
33 matches
Mail list logo
