* bug#15801: 15801: commit identified
2013-11-04 18:42 bug#15801: 24.3.50; bar scrolling freezes gtk emacs Jarek Czekalski
@ 2013-11-05 12:57 ` Jarek Czekalski
2013-11-06 19:48 ` bug#15801: it's a different revision, 112892 Jarek Czekalski
` (10 subsequent siblings)
11 siblings, 0 replies; 32+ messages in thread
From: Jarek Czekalski @ 2013-11-05 12:57 UTC (permalink / raw)
To: 15801
I isolated the commit that causes the problem on my machine:
revno: 112859
committer: Paul Eggert <>
branch nick: trunk
timestamp: Wed 2013-06-05 10:04:13 -0700
message:
Chain glib's SIGCHLD handler from Emacs's (Bug#14474).
* process.c (dummy_handler): New function.
(lib_child_handler): New static var.
(handle_child_signal): Invoke it.
(catch_child_signal): If a library has set up a signal handler,
save it into lib_child_handler.
(init_process_emacs): If using glib and not on Windows, tickle glib's
child-handling code so that it initializes its private SIGCHLD handler.
* syssignal.h (SA_SIGINFO): Default to 0.
* xterm.c (x_term_init): Remove D-bus hack that I installed on May
31; it should no longer be needed now.
I guess the next step would be isolating the single change.
Jarek
^ permalink raw reply [flat|nested] 32+ messages in thread* bug#15801: it's a different revision, 112892
2013-11-04 18:42 bug#15801: 24.3.50; bar scrolling freezes gtk emacs Jarek Czekalski
2013-11-05 12:57 ` bug#15801: 15801: commit identified Jarek Czekalski
@ 2013-11-06 19:48 ` Jarek Czekalski
2013-11-21 6:00 ` Jan Djärv
2013-11-30 17:04 ` Jarek Czekalski
` (9 subsequent siblings)
11 siblings, 1 reply; 32+ messages in thread
From: Jarek Czekalski @ 2013-11-06 19:48 UTC (permalink / raw)
To: 15801
First of all I apologize for giving the wrong revision number in my
previous report.
When I tried to isolate the piece of code that introduces problems, I
finally gave up. This all revision may be applied and all works. So I
did more binary search and finally I'm sure the one below is the right
revision.
------------------------------------------------------------
revno: 112892
committer: Jan D. <jan.h.d@swipnet.se>
branch nick: trunk
timestamp: Sat 2013-06-08 10:48:52 +0200
message:
* xgselect.c (xg_select): Remove call to window_system_available
and g_main_context_pending at the top, so Gdk events (i.e. file
notify) are processed when Emacs is started with -nw.
It's quite short:
=== modified file 'src/xgselect.c'
@@ -44,9 +44,13 @@
- if (! (window_system_available (NULL)
- && g_main_context_pending (context = g_main_context_default ())))
- return pselect (fds_lim, rfds, wfds, efds, timeout, sigmask);
+ /* Do not try to optimize with an initial check with
g_main_context_pending
+ and a call to pselect if it returns false. If Gdk has a timeout
for 0.01
+ second, and Emacs has a timeout for 1 second,
g_main_context_pending will
+ return false, but the timeout will be 1 second, thus missing the gdk
+ timeout with a lot. */
+
+ context = g_main_context_default ();
When I apply the code removed in this revision to the current trunk, I
have a relief. No more freezing, as well as with my first fix that also
works.
Jarek
^ permalink raw reply [flat|nested] 32+ messages in thread* bug#15801: it's a different revision, 112892
2013-11-06 19:48 ` bug#15801: it's a different revision, 112892 Jarek Czekalski
@ 2013-11-21 6:00 ` Jan Djärv
2013-11-21 7:25 ` bug#15801: 24.3.50; bar scrolling freezes gtk emacs Jarek Czekalski
0 siblings, 1 reply; 32+ messages in thread
From: Jan Djärv @ 2013-11-21 6:00 UTC (permalink / raw)
To: Jarek Czekalski; +Cc: 15801
Hello.
6 nov 2013 kl. 20:48 skrev Jarek Czekalski <jarekczek@poczta.onet.pl>:
> First of all I apologize for giving the wrong revision number in my previous report.
>
> When I tried to isolate the piece of code that introduces problems, I finally gave up. This all revision may be applied and all works. So I did more binary search and finally I'm sure the one below is the right revision.
It seems like Emacs stops receiving SIGIO. If it is blocked or if Gtk+ stole the signal handler I don't know yet.
Jan D.
>
> ------------------------------------------------------------
> revno: 112892
> committer: Jan D. <jan.h.d@swipnet.se>
> branch nick: trunk
> timestamp: Sat 2013-06-08 10:48:52 +0200
> message:
> * xgselect.c (xg_select): Remove call to window_system_available
> and g_main_context_pending at the top, so Gdk events (i.e. file
> notify) are processed when Emacs is started with -nw.
>
> It's quite short:
>
> === modified file 'src/xgselect.c'
> @@ -44,9 +44,13 @@
>
> - if (! (window_system_available (NULL)
> - && g_main_context_pending (context = g_main_context_default ())))
> - return pselect (fds_lim, rfds, wfds, efds, timeout, sigmask);
> + /* Do not try to optimize with an initial check with g_main_context_pending
> + and a call to pselect if it returns false. If Gdk has a timeout for 0.01
> + second, and Emacs has a timeout for 1 second, g_main_context_pending will
> + return false, but the timeout will be 1 second, thus missing the gdk
> + timeout with a lot. */
> +
> + context = g_main_context_default ();
>
> When I apply the code removed in this revision to the current trunk, I have a relief. No more freezing, as well as with my first fix that also works.
>
> Jarek
>
>
^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#15801: 24.3.50; bar scrolling freezes gtk emacs
2013-11-21 6:00 ` Jan Djärv
@ 2013-11-21 7:25 ` Jarek Czekalski
2013-11-30 11:41 ` Jan Djärv
0 siblings, 1 reply; 32+ messages in thread
From: Jarek Czekalski @ 2013-11-21 7:25 UTC (permalink / raw)
To: 15801
W dniu 2013-11-21 07:00, Jan Djärv pisze:
> It seems like Emacs stops receiving SIGIO. If it is blocked or if Gtk+ stole the signal handler I don't know yet.
Sounds interesting, waiting for more info. I will be glad to learn more
about signals. This is what I read on
http://unixhelp.ed.ac.uk/CGI/man-cgi?signal+7, maybe it will be relevant:
If more than one of the
threads has the signal unblocked, then the kernel chooses an
arbitrary
thread to which to deliver the signal.
There are several threads in action (some belonging to gtk), so this
tells me Emacs cannot be sure to receive any kernel signal. Gtk uses the
term signal for a different thing, it makes googling difficult.
Jarek
^ permalink raw reply [flat|nested] 32+ messages in thread* bug#15801: 24.3.50; bar scrolling freezes gtk emacs
2013-11-21 7:25 ` bug#15801: 24.3.50; bar scrolling freezes gtk emacs Jarek Czekalski
@ 2013-11-30 11:41 ` Jan Djärv
2013-11-30 11:54 ` Eli Zaretskii
0 siblings, 1 reply; 32+ messages in thread
From: Jan Djärv @ 2013-11-30 11:41 UTC (permalink / raw)
To: Jarek Czekalski; +Cc: 15801
Hello.
21 nov 2013 kl. 08:25 skrev Jarek Czekalski <jarekczek@poczta.onet.pl>:
> W dniu 2013-11-21 07:00, Jan Djärv pisze:
>> It seems like Emacs stops receiving SIGIO. If it is blocked or if Gtk+ stole the signal handler I don't know yet.
>
> Sounds interesting, waiting for more info. I will be glad to learn more about signals. This is what I read on http://unixhelp.ed.ac.uk/CGI/man-cgi?signal+7, maybe it will be relevant:
>
> If more than one of the
> threads has the signal unblocked, then the kernel chooses an arbitrary
> thread to which to deliver the signal.
>
> There are several threads in action (some belonging to gtk), so this tells me Emacs cannot be sure to receive any kernel signal. Gtk uses the term signal for a different thing, it makes googling difficult.
Actually the signal handling is sane. It is somthing else.
In xdisp.c, redisplay_internal there is a path that turns off SIGIO and never turn it on again.
I.e.:
enter redisplay_internal
unrequest_sigio() /* Two paths to do this in the code */
goto retry /* Many places */
goto end_of_redisplay /* One place */
When this path in the code is taken, SIGIO is off (blocked) and never turned on again, and Emacs freezes.
Cc:ing Eli. The obvious fix would be to request_sigio before exit. Is there any side effects to this?
This is very hard to reproduce. I have to scroll like mad on a slow computer to see it. On a faster computer I can't reproduce it. I guess it has to do something with the time redisplay takes.
Jan D.
^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#15801: 24.3.50; bar scrolling freezes gtk emacs
2013-11-30 11:41 ` Jan Djärv
@ 2013-11-30 11:54 ` Eli Zaretskii
2013-11-30 12:51 ` Jan Djärv
0 siblings, 1 reply; 32+ messages in thread
From: Eli Zaretskii @ 2013-11-30 11:54 UTC (permalink / raw)
To: Jan Djärv; +Cc: 15801, jarekczek
> From: Jan Djärv <jan.h.d@swipnet.se>
> Date: Sat, 30 Nov 2013 12:41:27 +0100
> Cc: 15801@debbugs.gnu.org,
> Eli Zaretskii <eliz@gnu.org>
>
> enter redisplay_internal
> unrequest_sigio() /* Two paths to do this in the code */
> goto retry /* Many places */
> goto end_of_redisplay /* One place */
>
> When this path in the code is taken, SIGIO is off (blocked) and never turned on again, and Emacs freezes.
>
> Cc:ing Eli. The obvious fix would be to request_sigio before exit. Is there any side effects to this?
If you call request_sigio only if interrupts_deferred is non-zero, I
see no adverse side effects.
In any case, code paths that turn off SIGIO and never turn it on again
are obvious bugs. Thanks for finding this one.
^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#15801: 24.3.50; bar scrolling freezes gtk emacs
2013-11-30 11:54 ` Eli Zaretskii
@ 2013-11-30 12:51 ` Jan Djärv
2013-11-30 13:55 ` Eli Zaretskii
0 siblings, 1 reply; 32+ messages in thread
From: Jan Djärv @ 2013-11-30 12:51 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 15801, Jarek Czekalski
Hello.
30 nov 2013 kl. 12:54 skrev Eli Zaretskii <eliz@gnu.org>:
>> From: Jan Djärv <jan.h.d@swipnet.se>
>> Date: Sat, 30 Nov 2013 12:41:27 +0100
>> Cc: 15801@debbugs.gnu.org,
>> Eli Zaretskii <eliz@gnu.org>
>>
>> enter redisplay_internal
>> unrequest_sigio() /* Two paths to do this in the code */
>> goto retry /* Many places */
>> goto end_of_redisplay /* One place */
>>
>> When this path in the code is taken, SIGIO is off (blocked) and never turned on again, and Emacs freezes.
>>
>> Cc:ing Eli. The obvious fix would be to request_sigio before exit. Is there any side effects to this?
>
> If you call request_sigio only if interrupts_deferred is non-zero, I
> see no adverse side effects.
>
> In any case, code paths that turn off SIGIO and never turn it on again
> are obvious bugs. Thanks for finding this one.
OK, I checked in a fix. I can't reproduce the bug with this, but I had a hard time reproducing it anyway.
Jan D.
^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#15801: 24.3.50; bar scrolling freezes gtk emacs
2013-11-30 12:51 ` Jan Djärv
@ 2013-11-30 13:55 ` Eli Zaretskii
2013-11-30 14:05 ` Jan Djärv
2013-11-30 18:11 ` Jarek Czekalski
0 siblings, 2 replies; 32+ messages in thread
From: Eli Zaretskii @ 2013-11-30 13:55 UTC (permalink / raw)
To: Jan Djärv; +Cc: 15801, jarekczek
> From: Jan Djärv <jan.h.d@swipnet.se>
> Date: Sat, 30 Nov 2013 13:51:11 +0100
> Cc: Jarek Czekalski <jarekczek@poczta.onet.pl>,
> 15801@debbugs.gnu.org
>
> >> Cc:ing Eli. The obvious fix would be to request_sigio before exit. Is there any side effects to this?
> >
> > If you call request_sigio only if interrupts_deferred is non-zero, I
> > see no adverse side effects.
> >
> > In any case, code paths that turn off SIGIO and never turn it on again
> > are obvious bugs. Thanks for finding this one.
>
> OK, I checked in a fix. I can't reproduce the bug with this, but I had a hard time reproducing it anyway.
Thanks, but it looks like you called unrequest_sigio instead of
request_sigio ;-)
^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#15801: 24.3.50; bar scrolling freezes gtk emacs
2013-11-30 13:55 ` Eli Zaretskii
@ 2013-11-30 14:05 ` Jan Djärv
2013-11-30 18:11 ` Jarek Czekalski
1 sibling, 0 replies; 32+ messages in thread
From: Jan Djärv @ 2013-11-30 14:05 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 15801, Jarek Czekalski
30 nov 2013 kl. 14:55 skrev Eli Zaretskii <eliz@gnu.org>:
> Thanks, but it looks like you called unrequest_sigio instead of
> request_sigio ;-)
Drat! Fixed.
Jan D.
^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#15801: 24.3.50; bar scrolling freezes gtk emacs
2013-11-30 13:55 ` Eli Zaretskii
2013-11-30 14:05 ` Jan Djärv
@ 2013-11-30 18:11 ` Jarek Czekalski
2013-11-30 18:38 ` Eli Zaretskii
1 sibling, 1 reply; 32+ messages in thread
From: Jarek Czekalski @ 2013-11-30 18:11 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 15801
W dniu 2013-11-30 14:55, Eli Zaretskii pisze:
>>
>>>> Cc:ing Eli. The obvious fix would be to request_sigio before exit. Is there any side effects to this?
>>> If you call request_sigio only if interrupts_deferred is non-zero, I
>>> see no adverse side effects.
Well, the old code does not bother checking interrupts_deferred. Is this
important?
if (interrupt_input)
request_sigio ();
RESUME_POLLING;
Jarek
^ permalink raw reply [flat|nested] 32+ messages in thread* bug#15801: 24.3.50; bar scrolling freezes gtk emacs
2013-11-30 18:11 ` Jarek Czekalski
@ 2013-11-30 18:38 ` Eli Zaretskii
0 siblings, 0 replies; 32+ messages in thread
From: Eli Zaretskii @ 2013-11-30 18:38 UTC (permalink / raw)
To: Jarek Czekalski; +Cc: 15801
> Date: Sat, 30 Nov 2013 19:11:40 +0100
> From: Jarek Czekalski <jarekczek@poczta.onet.pl>
> CC: Jan Djärv <jan.h.d@swipnet.se>,
> 15801@debbugs.gnu.org
>
>
> W dniu 2013-11-30 14:55, Eli Zaretskii pisze:
> >>
> >>>> Cc:ing Eli. The obvious fix would be to request_sigio before exit. Is there any side effects to this?
> >>> If you call request_sigio only if interrupts_deferred is non-zero, I
> >>> see no adverse side effects.
>
> Well, the old code does not bother checking interrupts_deferred. Is this
> important?
Look at what request_sigio does.
^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#15801: 24.3.50; bar scrolling freezes gtk emacs
2013-11-04 18:42 bug#15801: 24.3.50; bar scrolling freezes gtk emacs Jarek Czekalski
2013-11-05 12:57 ` bug#15801: 15801: commit identified Jarek Czekalski
2013-11-06 19:48 ` bug#15801: it's a different revision, 112892 Jarek Czekalski
@ 2013-11-30 17:04 ` Jarek Czekalski
2013-11-30 23:16 ` Jan Djärv
2013-11-30 17:10 ` bug#15801: 24.3.50; bar scrolling freezes gtk emacs - stdout warning Jarek Czekalski
` (8 subsequent siblings)
11 siblings, 1 reply; 32+ messages in thread
From: Jarek Czekalski @ 2013-11-30 17:04 UTC (permalink / raw)
To: 15801
[-- Attachment #1: Type: text/plain, Size: 1741 bytes --]
Jan,
Thank you for the attempt. It must be very difficult to work on it,
without being able to reproduce as easily as it happens on my side.
The attempt failed. The code you inserted is never reached. Even if I
make it reachable (reducing the condition to "interrupt_input" or make
it executed always), still hanging occurs with the same ease.
What you fix is probably introduced a very long time ago (before
r31171), with copy and paste programming method. This could be more
readable as part of STOP_POLLING and
RESUME_POLLING macros (or maybe even part of stop_polling?). I prepared
a patch making it so. This has nothing to do with copyright, the idea is
yours, so please don't credit me in this case. Anyway I posted an
assignment 2 weeks ago, maybe it arrived already. This is only code
rearrangement, without any behavior change, so you may skip it as well.
Further discoveries:
1. Making unrequest_sigio never called does not remove the freeze (in
one attempt it even appeared sooner)
2. Placing STOP_POLLING (patched, containing unrequest) at the very
beginning of redisplay_internal seems to make no detectable change
Maybe one of these changes would make it reproducable at your box?
When I was debugging threading issues in Java I used a function
debugDelay(int n) which simulated computations. This could be inserted
in various places to make bugs reproducable by anyone. Of course finding
the right place(s) is truly difficult. Maybe this method could be
applied here. If we don't have such a helper function, I can write it.
It must trick the compiler, so it not optimize the fictional loop. But I
can't help in finding the right place to insert it, because I reproduce
it in a blink of an eye.
Jarek
[-- Attachment #2: req_sigio_1_0.txt --]
[-- Type: text/plain, Size: 3177 bytes --]
=== modified file 'src/xdisp.c'
--- src/xdisp.c 2013-11-30 14:03:53 +0000
+++ src/xdisp.c 2013-11-30 16:04:59 +0000
@@ -13119,13 +13119,28 @@
}
}
-#define STOP_POLLING \
-do { if (! polling_stopped_here) stop_polling (); \
- polling_stopped_here = 1; } while (0)
+#define STOP_POLLING \
+do { \
+ if (! polling_stopped_here) stop_polling (); \
+ polling_stopped_here = 1; \
+ /* Prevent various kinds of signals during display \
+ update. stdio is not robust about handling \
+ signals, which can cause an apparent I/O error. */ \
+ if (interrupt_input) \
+ unrequest_sigio (); \
+} while (0)
-#define RESUME_POLLING \
-do { if (polling_stopped_here) start_polling (); \
- polling_stopped_here = 0; } while (0)
+#define RESUME_POLLING \
+do { \
+ if (polling_stopped_here) start_polling (); \
+ polling_stopped_here = 0; \
+ /* Start SIGIO interrupts coming again. Having them off during the \
+ code above makes it less likely one will discard output, but not \
+ impossible, since there might be stuff in the system buffer here. \
+ But it is much hairier to try to do anything about that. */ \
+ if (interrupt_input) \
+ request_sigio (); \
+} while (0)
/* Perhaps in the future avoid recentering windows if it
@@ -13627,11 +13642,6 @@
goto retry_frame;
}
- /* Prevent various kinds of signals during display
- update. stdio is not robust about handling
- signals, which can cause an apparent I/O error. */
- if (interrupt_input)
- unrequest_sigio ();
STOP_POLLING;
pending |= update_frame (f, 0, 0);
@@ -13684,11 +13694,6 @@
if (sf->fonts_changed)
goto retry;
- /* Prevent various kinds of signals during display update.
- stdio is not robust about handling signals,
- which can cause an apparent I/O error. */
- if (interrupt_input)
- unrequest_sigio ();
STOP_POLLING;
if (FRAME_VISIBLE_P (sf) && !FRAME_OBSCURED_P (sf))
@@ -13761,12 +13766,6 @@
windows_or_buffers_changed = 0;
}
- /* Start SIGIO interrupts coming again. Having them off during the
- code above makes it less likely one will discard output, but not
- impossible, since there might be stuff in the system buffer here.
- But it is much hairier to try to do anything about that. */
- if (interrupt_input)
- request_sigio ();
RESUME_POLLING;
/* If a frame has become visible which was not before, redisplay
@@ -13819,8 +13818,6 @@
#endif /* HAVE_WINDOW_SYSTEM */
end_of_redisplay:
- if (interrupt_input && interrupts_deferred)
- request_sigio ();
unbind_to (count, Qnil);
RESUME_POLLING;
^ permalink raw reply [flat|nested] 32+ messages in thread* bug#15801: 24.3.50; bar scrolling freezes gtk emacs
2013-11-30 17:04 ` Jarek Czekalski
@ 2013-11-30 23:16 ` Jan Djärv
[not found] ` <529AF507.5080509@poczta.onet.pl>
0 siblings, 1 reply; 32+ messages in thread
From: Jan Djärv @ 2013-11-30 23:16 UTC (permalink / raw)
To: Jarek Czekalski; +Cc: 15801
Hello.
30 nov 2013 kl. 18:04 skrev Jarek Czekalski <jarekczek@poczta.onet.pl>:
> Jan,
>
> Thank you for the attempt. It must be very difficult to work on it, without being able to reproduce as easily as it happens on my side.
>
> The attempt failed. The code you inserted is never reached.
It is indeed reached. Maybe not when you encountered the freeze. I traced the signal mask and (un)request_sigio calls, and everytime I got a freeze, it was because unrequest_sigio had been called but request_sigio had not been called.
You obviously have a different freeze.
> Even if I make it reachable (reducing the condition to "interrupt_input" or make it executed always), still hanging occurs with the same ease.
>
> What you fix is probably introduced a very long time ago (before r31171), with copy and paste programming method.
This sentence I can't understand
> This could be more readable as part of STOP_POLLING and
> RESUME_POLLING macros (or maybe even part of stop_polling?). I prepared a patch making it so. This has nothing to do with copyright, the idea is yours, so please don't credit me in this case. Anyway I posted an assignment 2 weeks ago, maybe it arrived already. This is only code rearrangement, without any behavior change, so you may skip it as well.
POLLING and SIGIO are two different concepts, it would be very unclear to put SIGIO operations in a POLLING macro.
>
> Further discoveries:
> 1. Making unrequest_sigio never called does not remove the freeze (in one attempt it even appeared sooner)
> 2. Placing STOP_POLLING (patched, containing unrequest) at the very beginning of redisplay_internal seems to make no detectable change
> Maybe one of these changes would make it reproducable at your box?
>
> When I was debugging threading issues in Java I used a function debugDelay(int n) which simulated computations. This could be inserted in various places to make bugs reproducable by anyone. Of course finding the right place(s) is truly difficult. Maybe this method could be applied here. If we don't have such a helper function, I can write it. It must trick the compiler, so it not optimize the fictional loop. But I can't help in finding the right place to insert it, because I reproduce it in a blink of an eye.
I guess you have to debug it.
Jan D.
^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#15801: 24.3.50; bar scrolling freezes gtk emacs - stdout warning
2013-11-04 18:42 bug#15801: 24.3.50; bar scrolling freezes gtk emacs Jarek Czekalski
` (2 preceding siblings ...)
2013-11-30 17:04 ` Jarek Czekalski
@ 2013-11-30 17:10 ` Jarek Czekalski
2013-12-02 8:04 ` bug#15801: 24.3.50; bar scrolling freezes gtk emacs Jarek Czekalski
` (7 subsequent siblings)
11 siblings, 0 replies; 32+ messages in thread
From: Jarek Czekalski @ 2013-11-30 17:10 UTC (permalink / raw)
To: 15801
Warning: don't put much debugging output to stdout, it ceases the freeze
as well.
^ permalink raw reply [flat|nested] 32+ messages in thread* bug#15801: 24.3.50; bar scrolling freezes gtk emacs
2013-11-04 18:42 bug#15801: 24.3.50; bar scrolling freezes gtk emacs Jarek Czekalski
` (3 preceding siblings ...)
2013-11-30 17:10 ` bug#15801: 24.3.50; bar scrolling freezes gtk emacs - stdout warning Jarek Czekalski
@ 2013-12-02 8:04 ` Jarek Czekalski
2013-12-02 8:18 ` Jarek Czekalski
` (6 subsequent siblings)
11 siblings, 0 replies; 32+ messages in thread
From: Jarek Czekalski @ 2013-12-02 8:04 UTC (permalink / raw)
To: 15801
Jan, you got lost with the commit 112892 of yours. You say it has
nothing to do with -nw, but in the message log you mention -nw. Please
have one more look at it (at the whole commit), to see that I'm right.
That's important, because I see a real problem with this commit.
When you created xgselect.c file in r98730 you placed the following
lines there:
| /* Update event sources in GLib. */
| g_main_context_pending (context);
As I understand it is that this call is important to update glib sources
(possibly glib file descriptors too - my guess).
In r109774 Paul removes this comment, while keeping the call to
g_main_context_pending, but conditionally:
+ if (! (x_in_use
+ && g_main_context_pending (context = g_main_context_default ())))
In r112892 you say that call to g_main_context_pending is not needed at
all, because it was a bad optimization, which you corrected.
This is a mistake, isn't it?
As a side note: I'm still trying to investigate my freeze. So far I know
that in the "freezed" state xgselect returns non-zero, while
XTread_socket returns 0. And this happens repeatedly and very quickly.
Side note 2: detailed description of the bug being fixed in a commit is
very important. Otherwise after just a few months we don't know what we
really fixed. A link to a bug report or to a discussion on a mailing
list would be very valueable. We don't have this information in commit
r112892.
Another concern when I analyze xgselect is why we increase the number of
tested selectors over the number requested by the caller? If a caller
receives a positive number, it thinks that there is something to read.
But it will check only the descriptors up to the number it specified in
the call. This doesn't make sense to me. Shouldn't it be specified in
the documentation of xgselect, that it may surprise caller with false
positives? This is not the usual behaviour of select-like calls, is it?
And this is something that was changed by your commit. Previously a
standard pselect was returned (under some circumstances). After that,
the extended version, with false positives.
Jarek
^ permalink raw reply [flat|nested] 32+ messages in thread* bug#15801: 24.3.50; bar scrolling freezes gtk emacs
2013-11-04 18:42 bug#15801: 24.3.50; bar scrolling freezes gtk emacs Jarek Czekalski
` (4 preceding siblings ...)
2013-12-02 8:04 ` bug#15801: 24.3.50; bar scrolling freezes gtk emacs Jarek Czekalski
@ 2013-12-02 8:18 ` Jarek Czekalski
2013-12-02 17:11 ` Jarek Czekalski
` (5 subsequent siblings)
11 siblings, 0 replies; 32+ messages in thread
From: Jarek Czekalski @ 2013-12-02 8:18 UTC (permalink / raw)
To: 15801
The last paragraph, about false positives, seems like it was my mistake.
I'm sorry for that.
Jarek
^ permalink raw reply [flat|nested] 32+ messages in thread* bug#15801: 24.3.50; bar scrolling freezes gtk emacs
2013-11-04 18:42 bug#15801: 24.3.50; bar scrolling freezes gtk emacs Jarek Czekalski
` (5 preceding siblings ...)
2013-12-02 8:18 ` Jarek Czekalski
@ 2013-12-02 17:11 ` Jarek Czekalski
2013-12-03 22:27 ` Jarek Czekalski
` (4 subsequent siblings)
11 siblings, 0 replies; 32+ messages in thread
From: Jarek Czekalski @ 2013-12-02 17:11 UTC (permalink / raw)
To: 15801
Anyway adding a g_main_context_pending call alone does not solve the
issue. Explaining the mystery of removal of this call may not be worth
its time. I'll concentrate on SIGIO as suggested by Jan and report when
I have something on this subject.
^ permalink raw reply [flat|nested] 32+ messages in thread* bug#15801: 24.3.50; bar scrolling freezes gtk emacs
2013-11-04 18:42 bug#15801: 24.3.50; bar scrolling freezes gtk emacs Jarek Czekalski
` (6 preceding siblings ...)
2013-12-02 17:11 ` Jarek Czekalski
@ 2013-12-03 22:27 ` Jarek Czekalski
2013-12-04 20:28 ` Jarek Czekalski
` (3 subsequent siblings)
11 siblings, 0 replies; 32+ messages in thread
From: Jarek Czekalski @ 2013-12-03 22:27 UTC (permalink / raw)
To: 15801
It's not about sigio. Inside xg_select, which is called with high
frequency inside the freeze, the sigmask has not sigio set. Even if I
try to force the freeze calling unrequest_sigio (and sigmask indeed
changes), still the behaviour does not differ. Emacs is responsive until
I want to play scrolling bars with it.
What I discovered so far:
1. Inside the freeze xg_select always returns 1, due to active
descriptor 7 (in my case it's number 7). This is the descriptor received
from ConnectionNumber (x11) and inserted into input_wait_mask through
add_keyboard_wait_descriptor
2. gtk detects no events pending during the freeze
3. gdk event filter is not called
This contradiction (input from x11, but no gtk events) suggests to me
that something's wrong between gtk and x, in gdk x11 module. So gtk
version may be important. It is included in the initial report, 3.8.4.
No change in 3.8.6-1. When I compiled 3.11.2 (the hottest gtk tag),
emacs does not freeze, but displays white screen instead of the text
area, only momentarily showing traces of the true content.
I'll report again when I know something for sure. I'm not giving up yet :)
By the way: g_main_context_query call in xg_select is theoretically
illegal, because it should be wrapped inside g_main_context_acquire.
Also g_main_context_prepare is suggested before "query". Anyway adding
both these calls does not help the freeze.
Jarek
^ permalink raw reply [flat|nested] 32+ messages in thread* bug#15801: 24.3.50; bar scrolling freezes gtk emacs
2013-11-04 18:42 bug#15801: 24.3.50; bar scrolling freezes gtk emacs Jarek Czekalski
` (7 preceding siblings ...)
2013-12-03 22:27 ` Jarek Czekalski
@ 2013-12-04 20:28 ` Jarek Czekalski
2013-12-05 17:08 ` Jarek Czekalski
2013-12-08 16:14 ` Jarek Czekalski
` (2 subsequent siblings)
11 siblings, 1 reply; 32+ messages in thread
From: Jarek Czekalski @ 2013-12-04 20:28 UTC (permalink / raw)
To: 15801
[-- Attachment #1: Type: text/plain, Size: 1304 bytes --]
I have bad news. It's time to think about the call to
g_main_context_query, because it seems to destroy the fragile workflow
of gtk. There are timeout triggered events "pause-events" and
"resume-events". Every mouse movement triggers one pause and one resume.
In my case finally pause is called twice while resume - once. There goes
the freeze.
I attach gdb backtraces for you to see what is the code flow to reach
those pause and resume methods. Breakpoints were set in
_gdk_display_pause_events
_gdk_display_unpause_events
Source codes used are:
gtk 3.8.6
glib 2.36.4
emacs r115317
Now I know why the commit r112892 causes troubles. Because it enables
the code path in which the code unbalancing gtk is run. Why this code
may be run safely when events are pending? Maybe because in this case
polling doesn't change anything, events are pending anyway. But this is
a guess. What is sure is that you can't take just one gtk method and use
it out of the context for which it was designed. It causes big troubles,
for a guy who wants to debug the problem. You never know when it
strikes. Let's make it safe.
The first thing I would do now is finding the real bugs that were being
fixed by r112892. Maybe there is another way of fixing them, without
calling g_main_context_query.
Jarek
[-- Attachment #2: backtrace.txt --]
[-- Type: text/plain, Size: 12092 bytes --]
Script started on Wed 04 Dec 2013 09:22:42 PM CET
jcdeb:/home# gdb --args emacs -Q
GNU gdb (GDB) 7.6.1 (Debian 7.6.1-1)
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/local/bin/emacs-24.3.50...done.
(gdb) start
Temporary breakpoint 1 at 0x8058350: file emacs.c, line 688.
Starting program: /usr/local/bin/emacs -Q
warning: Could not load shared library symbols for linux-gate.so.1.
Do you need "set solib-search-path" or "set sysroot"?
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/i686/cmov/libthread_db.so.1".
Temporary breakpoint 1, main (argc=2, argv=0xbffff544) at emacs.c:688
688 {
(gdb) break _gdk_display_pause_events
Breakpoint 2 at 0xb78f2f40: file gdkdisplay.c, line 2012.
(gdb) break _gdk_display_pause_events\b\b\b\b\b\b\b\b\b\b\b\b^[[1@u^[[1@n
Breakpoint 3 at 0xb78f2f50: file gdkdisplay.c, line 2018.
(gdb) cont
Continuing.
[New Thread 0xb5f07b40 (LWP 29235)]
[New Thread 0xb552fb40 (LWP 29237)]
[New Thread 0xb4bffb40 (LWP 29239)]
Breakpoint 2, _gdk_display_pause_events (display=display@entry=0x8858840)
at gdkdisplay.c:2012
2012 {
(gdb) backtrace
#0 _gdk_display_pause_events (display=display@entry=0x8858840)
at gdkdisplay.c:2012
#1 0xb78ffa2e in gdk_window_flush_events (clock=0x8861150, data=0x885f980)
at gdkwindow.c:11611
#2 0xb7551339 in g_cclosure_marshal_VOID__VOIDv (closure=0x85c9570,
return_value=0x0, instance=0x8861150, args=0xbfffe978 "",
marshal_data=0x0, n_params=0, param_types=0x0)
at /build/glib2.0-Ot8bbC/glib2.0-2.36.4/./gobject/gmarshal.c:115
#3 0xb754f8de in _g_closure_invoke_va (closure=closure@entry=0x85c9570,
return_value=return_value@entry=0x0, instance=instance@entry=0x8861150,
args=args@entry=0xbfffe978 "", n_params=0, param_types=0x0)
at /build/glib2.0-Ot8bbC/glib2.0-2.36.4/./gobject/gclosure.c:840
#4 0xb7568237 in g_signal_emit_valist (instance=instance@entry=0x8861150,
signal_id=signal_id@entry=136, detail=detail@entry=0,
var_args=var_args@entry=0xbfffe978 "")
at /build/glib2.0-Ot8bbC/glib2.0-2.36.4/./gobject/gsignal.c:3234
#5 0xb7569291 in g_signal_emit_by_name (instance=instance@entry=0x8861150,
detailed_signal=detailed_signal@entry=0xb7938973 "flush-events")
at /build/glib2.0-Ot8bbC/glib2.0-2.36.4/./gobject/gsignal.c:3424
#6 0xb78f936d in gdk_frame_clock_flush_idle (data=0x8861150)
at gdkframeclockidle.c:312
#7 0xb78eafc5 in gdk_threads_dispatch (data=data@entry=0x8a0dfb0) at gdk.c:788
#8 0xb74850b1 in g_timeout_dispatch (source=source@entry=0x89ee6a8,
---Type <return> to continue, or q <return> to quit---
callback=0xb78eaf90 <gdk_threads_dispatch>, user_data=0x8a0dfb0)
at /build/glib2.0-Ot8bbC/glib2.0-2.36.4/./glib/gmain.c:4413
#9 0xb748442e in g_main_dispatch (context=0x884a1e8, context@entry=0x883a220)
at /build/glib2.0-Ot8bbC/glib2.0-2.36.4/./glib/gmain.c:3054
#10 g_main_context_dispatch (context=context@entry=0x884a1e8)
at /build/glib2.0-Ot8bbC/glib2.0-2.36.4/./glib/gmain.c:3630
#11 0xb74847d8 in g_main_context_iterate (context=context@entry=0x884a1e8,
block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>)
at /build/glib2.0-Ot8bbC/glib2.0-2.36.4/./glib/gmain.c:3701
#12 0xb7484898 in g_main_context_iteration (context=0x884a1e8,
context@entry=0x0, may_block=may_block@entry=1)
at /build/glib2.0-Ot8bbC/glib2.0-2.36.4/./glib/gmain.c:3762
#13 0xb7af0bd8 in gtk_main_iteration () at gtkmain.c:1260
#14 0x080f0091 in XTread_socket (terminal=0x8737818, hold_quit=0xbfffeb0c)
at xterm.c:7077
#15 0x08123519 in gobble_input () at keyboard.c:6841
#16 0x08122f95 in handle_async_input () at keyboard.c:7081
#17 process_pending_signals () at keyboard.c:7095
#18 0x08171939 in Fmake_list (length=length@entry=4, init=138857410)
at alloc.c:2597
#19 0x08190188 in concat (nargs=nargs@entry=1, args=args@entry=0xbfffec30,
target_type=Lisp_Cons, last_special=last_special@entry=false) at fns.c:578
#20 0x0819070e in Fcopy_sequence (arg=141242022) at fns.c:446
---Type <return> to continue, or q <return> to quit---
#21 0x08121e06 in timer_check () at keyboard.c:4559
#22 0x0812233b in readable_events (flags=flags@entry=1) at keyboard.c:3439
#23 0x0812361f in get_input_pending (flags=flags@entry=1) at keyboard.c:6756
#24 0x08126692 in detect_input_pending_run_timers (
do_display=do_display@entry=true) at keyboard.c:9879
#25 0x081c678f in wait_reading_process_output (time_limit=<optimized out>,
nsecs=nsecs@entry=0, read_kbd=read_kbd@entry=-1,
do_display=do_display@entry=true, wait_for_cell=138857410,
wait_proc=wait_proc@entry=0x0, just_wait_proc=just_wait_proc@entry=0)
at process.c:4680
#26 0x08062431 in sit_for (timeout=120, reading=reading@entry=true,
display_option=display_option@entry=1) at dispnew.c:5800
#27 0x08127383 in read_char (commandflag=1, map=map@entry=141054470,
prev_event=138857410, used_mouse_menu=used_mouse_menu@entry=0xbffff25b,
end_time=end_time@entry=0x0) at keyboard.c:2805
#28 0x0812865e in read_key_sequence (keybuf=keybuf@entry=0xbffff2f8,
prompt=138857410, dont_downcase_last=dont_downcase_last@entry=false,
can_return_switch_frame=can_return_switch_frame@entry=true,
fix_current_buffer=fix_current_buffer@entry=true,
prevent_redisplay=prevent_redisplay@entry=false, bufsize=30)
at keyboard.c:9074
#29 0x0812a016 in command_loop_1 () at keyboard.c:1445
#30 0x08189163 in internal_condition_case (
---Type <return> to continue, or q <return> to quit---
bfun=bfun@entry=0x8129e60 <command_loop_1>, handlers=138890506,
hfun=hfun@entry=0x8121750 <cmd_error>) at eval.c:1344
#31 0x0811d235 in command_loop_2 (ignore=138857410) at keyboard.c:1170
#32 0x08189093 in internal_catch (tag=138888554,
func=func@entry=0x811d210 <command_loop_2>, arg=138857410) at eval.c:1108
#33 0x081213a2 in command_loop () at keyboard.c:1149
#34 recursive_edit_1 () at keyboard.c:777
#35 0x08121663 in Frecursive_edit () at keyboard.c:841
#36 0x08058e88 in main (argc=<optimized out>, argv=0xbffff544) at emacs.c:1598
(gdb) cont
Continuing.
Breakpoint 3, _gdk_display_unpause_events (display=0x8858840)
at gdkdisplay.c:2018
2018 {
(gdb) backtrace
#0 _gdk_display_unpause_events (display=0x8858840) at gdkdisplay.c:2018
#1 0xb78ff9f3 in gdk_window_resume_events (clock=0x8861150, data=0x885f980)
at gdkwindow.c:11639
#2 0xb7551339 in g_cclosure_marshal_VOID__VOIDv (closure=0x85c9610,
return_value=0x0, instance=0x8861150, args=0xbfffe948 "?\022",
marshal_data=0x0, n_params=0, param_types=0x0)
at /build/glib2.0-Ot8bbC/glib2.0-2.36.4/./gobject/gmarshal.c:115
#3 0xb754f8de in _g_closure_invoke_va (closure=closure@entry=0x85c9610,
return_value=return_value@entry=0x0, instance=instance@entry=0x8861150,
args=args@entry=0xbfffe948 "?\022", n_params=0, param_types=0x0)
at /build/glib2.0-Ot8bbC/glib2.0-2.36.4/./gobject/gclosure.c:840
#4 0xb7568237 in g_signal_emit_valist (instance=instance@entry=0x8861150,
signal_id=signal_id@entry=142, detail=detail@entry=0,
var_args=var_args@entry=0xbfffe948 "?\022")
at /build/glib2.0-Ot8bbC/glib2.0-2.36.4/./gobject/gsignal.c:3234
#5 0xb7569291 in g_signal_emit_by_name (instance=instance@entry=0x8861150,
detailed_signal=detailed_signal@entry=0xb79389a0 "resume-events")
at /build/glib2.0-Ot8bbC/glib2.0-2.36.4/./gobject/gsignal.c:3424
#6 0xb78f98d4 in gdk_frame_clock_paint_idle (data=0x8861150)
at gdkframeclockidle.c:457
#7 0xb78eafc5 in gdk_threads_dispatch (data=data@entry=0x8a0df80) at gdk.c:788
#8 0xb74850b1 in g_timeout_dispatch (source=source@entry=0x88e9c80,
callback=0xb78eaf90 <gdk_threads_dispatch>, user_data=0x8a0df80)
---Type <return> to continue, or q <return> to quit---
at /build/glib2.0-Ot8bbC/glib2.0-2.36.4/./glib/gmain.c:4413
#9 0xb748442e in g_main_dispatch (context=0x884a1e8, context@entry=0x883a220)
at /build/glib2.0-Ot8bbC/glib2.0-2.36.4/./glib/gmain.c:3054
#10 g_main_context_dispatch (context=context@entry=0x884a1e8)
at /build/glib2.0-Ot8bbC/glib2.0-2.36.4/./glib/gmain.c:3630
#11 0xb74847d8 in g_main_context_iterate (context=context@entry=0x884a1e8,
block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>)
at /build/glib2.0-Ot8bbC/glib2.0-2.36.4/./glib/gmain.c:3701
#12 0xb7484898 in g_main_context_iteration (context=0x884a1e8,
context@entry=0x0, may_block=may_block@entry=1)
at /build/glib2.0-Ot8bbC/glib2.0-2.36.4/./glib/gmain.c:3762
#13 0xb7af0bd8 in gtk_main_iteration () at gtkmain.c:1260
#14 0x080f0091 in XTread_socket (terminal=0x8737818, hold_quit=0xbfffeb0c)
at xterm.c:7077
#15 0x08123519 in gobble_input () at keyboard.c:6841
#16 0x08122f95 in handle_async_input () at keyboard.c:7081
#17 process_pending_signals () at keyboard.c:7095
#18 0x08171939 in Fmake_list (length=length@entry=4, init=138857410)
at alloc.c:2597
#19 0x08190188 in concat (nargs=nargs@entry=1, args=args@entry=0xbfffec30,
target_type=Lisp_Cons, last_special=last_special@entry=false) at fns.c:578
#20 0x0819070e in Fcopy_sequence (arg=141242022) at fns.c:446
#21 0x08121e06 in timer_check () at keyboard.c:4559
---Type <return> to continue, or q <return> to quit---
#22 0x0812233b in readable_events (flags=flags@entry=1) at keyboard.c:3439
#23 0x0812361f in get_input_pending (flags=flags@entry=1) at keyboard.c:6756
#24 0x08126692 in detect_input_pending_run_timers (
do_display=do_display@entry=true) at keyboard.c:9879
#25 0x081c678f in wait_reading_process_output (time_limit=<optimized out>,
nsecs=nsecs@entry=0, read_kbd=read_kbd@entry=-1,
do_display=do_display@entry=true, wait_for_cell=138857410,
wait_proc=wait_proc@entry=0x0, just_wait_proc=just_wait_proc@entry=0)
at process.c:4680
#26 0x08062431 in sit_for (timeout=120, reading=reading@entry=true,
display_option=display_option@entry=1) at dispnew.c:5800
#27 0x08127383 in read_char (commandflag=1, map=map@entry=141054470,
prev_event=138857410, used_mouse_menu=used_mouse_menu@entry=0xbffff25b,
end_time=end_time@entry=0x0) at keyboard.c:2805
#28 0x0812865e in read_key_sequence (keybuf=keybuf@entry=0xbffff2f8,
prompt=138857410, dont_downcase_last=dont_downcase_last@entry=false,
can_return_switch_frame=can_return_switch_frame@entry=true,
fix_current_buffer=fix_current_buffer@entry=true,
prevent_redisplay=prevent_redisplay@entry=false, bufsize=30)
at keyboard.c:9074
#29 0x0812a016 in command_loop_1 () at keyboard.c:1445
#30 0x08189163 in internal_condition_case (
bfun=bfun@entry=0x8129e60 <command_loop_1>, handlers=138890506,
---Type <return> to continue, or q <return> to quit---
hfun=hfun@entry=0x8121750 <cmd_error>) at eval.c:1344
#31 0x0811d235 in command_loop_2 (ignore=138857410) at keyboard.c:1170
#32 0x08189093 in internal_catch (tag=138888554,
func=func@entry=0x811d210 <command_loop_2>, arg=138857410) at eval.c:1108
#33 0x081213a2 in command_loop () at keyboard.c:1149
#34 recursive_edit_1 () at keyboard.c:777
#35 0x08121663 in Frecursive_edit () at keyboard.c:841
#36 0x08058e88 in main (argc=<optimized out>, argv=0xbffff544) at emacs.c:1598
(gdb) delete
Delete all breakpoints? (y or n) y
(gdb) cont
Continuing.
[Thread 0xb4bffb40 (LWP 29239) exited]
[Thread 0xb552fb40 (LWP 29237) exited]
[Thread 0xb5f07b40 (LWP 29235) exited]
[Inferior 1 (process 29197) exited normally]
(gdb) quit
jcdeb:/home# exit
exit
Script done on Wed 04 Dec 2013 09:23:44 PM CET
^ permalink raw reply [flat|nested] 32+ messages in thread* bug#15801: 24.3.50; bar scrolling freezes gtk emacs
2013-12-04 20:28 ` Jarek Czekalski
@ 2013-12-05 17:08 ` Jarek Czekalski
2013-12-07 14:34 ` Jan Djärv
0 siblings, 1 reply; 32+ messages in thread
From: Jarek Czekalski @ 2013-12-05 17:08 UTC (permalink / raw)
To: 15801
I founded a way to freeze Emacs without using any syntax, that could be
considered incorrect from the glib/gtk point of view. At least nothing
incorrect stays in xgselect.
This is practically whole xg_select function, that still makes Emacs freeze:
context = g_main_context_default ();
while (g_main_context_iteration(context, 0)); // 0 = no wait
return 1;
So this makes context_query call free of any charges. I'm sorry for
blaming it for the problems. But it's so tempting when you see something
theoretically incorrect, to blame it for all the problems.
I'll try to locate the place in gtk that starts the problem. So far I
only know that the commit from gtk 3.7.10 introducing
motion compression is not yet making it freeze. Although that sounded
promising. So I'm starting binary search with gtk 3.7.10 being safe, and
3.8.4 failing. I hope to help with fixing it, because gtk 3.8.4 is going
to be used in next stable Debian, jessie, which is currently described
as testing.
Motion compression commit:
https://git.gnome.org/browse/gtk+/commit/gdk/gdkwindow.c?id=a69285da08a2a61d5fd817ee8ccb88a6b6deaef6
If someone is still listening, please help me gather statistics about
this bug. If you have:
1. libgtk-3 >=3.7.10
2. emacs built with gtk3
Please report through priv whether you reproduce or not. Tell me even if
you don't reproduce and send the output of /proc/cpuinfo. Mine is "Intel
Celeron 3.2G". My email: jarekczek # poczta.onet.pl.
Remember to make sure which gtk is actually used, for example using
"strace emacs -Q 2>&1 | grep libgtk"
Jarek
^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#15801: 24.3.50; bar scrolling freezes gtk emacs
2013-12-05 17:08 ` Jarek Czekalski
@ 2013-12-07 14:34 ` Jan Djärv
0 siblings, 0 replies; 32+ messages in thread
From: Jan Djärv @ 2013-12-07 14:34 UTC (permalink / raw)
To: Jarek Czekalski; +Cc: 15801
[-- Attachment #1: Type: text/plain, Size: 1981 bytes --]
Hello.
5 dec 2013 kl. 18:08 skrev Jarek Czekalski <jarekczek@poczta.onet.pl>:
> I founded a way to freeze Emacs without using any syntax, that could be considered incorrect from the glib/gtk point of view. At least nothing incorrect stays in xgselect.
>
> This is practically whole xg_select function, that still makes Emacs freeze:
>
> context = g_main_context_default ();
> while (g_main_context_iteration(context, 0)); // 0 = no wait
> return 1;
>
> So this makes context_query call free of any charges. I'm sorry for blaming it for the problems. But it's so tempting when you see something theoretically incorrect, to blame it for all the problems.
>
> I'll try to locate the place in gtk that starts the problem. So far I only know that the commit from gtk 3.7.10 introducing
> motion compression is not yet making it freeze. Although that sounded promising. So I'm starting binary search with gtk 3.7.10 being safe, and 3.8.4 failing. I hope to help with fixing it, because gtk 3.8.4 is going to be used in next stable Debian, jessie, which is currently described as testing.
>
> Motion compression commit:
> https://git.gnome.org/browse/gtk+/commit/gdk/gdkwindow.c?id=a69285da08a2a61d5fd817ee8ccb88a6b6deaef6
>
> If someone is still listening, please help me gather statistics about this bug. If you have:
> 1. libgtk-3 >=3.7.10
> 2. emacs built with gtk3
> Please report through priv whether you reproduce or not. Tell me even if you don't reproduce and send the output of /proc/cpuinfo. Mine is "Intel Celeron 3.2G". My email: jarekczek # poczta.onet.pl.
> Remember to make sure which gtk is actually used, for example using "strace emacs -Q 2>&1 | grep libgtk"
This whole clock-thing (enable/disable events in Gtk+) is quite new (3.7) , so I'd expect there will be bugs. As I said, I can't reproduce it on Gtk+ 3.8.6. Don't know why cpuinfo is relevant, I would suspect graphics driver more. But Gtk+ bugs the most.
Jan D.
[-- Attachment #2: cpuinfo --]
[-- Type: application/octet-stream, Size: 585 bytes --]
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 23
model name : Intel(R) Core(TM)2 Duo CPU T9550 @ 2.66GHz
stepping : 10
cpu MHz : 2653.000
cache size : 6144 KB
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx lm constant_tsc nopl xtopology pni ssse3 cx16 sse4_1 x2apic xsave hypervisor lahf_lm ida arat
bogomips : 5306.00
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#15801: 24.3.50; bar scrolling freezes gtk emacs
2013-11-04 18:42 bug#15801: 24.3.50; bar scrolling freezes gtk emacs Jarek Czekalski
` (8 preceding siblings ...)
2013-12-04 20:28 ` Jarek Czekalski
@ 2013-12-08 16:14 ` Jarek Czekalski
2013-12-08 23:29 ` Jarek Czekalski
2014-04-21 10:34 ` Jarek Czekalski
11 siblings, 0 replies; 32+ messages in thread
From: Jarek Czekalski @ 2013-12-08 16:14 UTC (permalink / raw)
To: 15801
[-- Attachment #1: Type: text/plain, Size: 3025 bytes --]
This time the posts consists of 3 parts: the poll, the bug, the patch.
THE POLL about reproducability
Jan - almost unable to reproduce using gtk 3.8.6 and 2 core Intel
2.6GHz. On a faster machine never reproduced.
Steve Berman - can't touch the scroll bar without a freeze, gtk 3.10.2,
AMD 3.4 GHz
Jarek - reproducing with a couple of scroll bar movements, gtk 3.8.x,
Celeron 3GHz
So at least 2 people are reproducing easily, including me.
THE BUG in gtk
I submitted a bug in gtk [1], as I suspect the motion events compression
introduced in 3.7.10 is responsible for the freeze. Unfortunately I
cannot reproduce without Emacs. Simply inserting gtk main loop call
inside motion event handler in gtk3demo app, plus some random delays,
does not allow to freeze it. Maybe breaking the chain of motion events
with something different is necessary.
In gtk 3.10 It will be possible to switch off the motion events
compression, as it introduces also another problems, as reported in gtk
bug [2], "motion_compression hurts precision for drawing". The switch is
not planned to be merged into 3.8.
In my opinion gtk with clocks and motion compression does not make sure
that the pausing/unpausing of events is always paired. Unpaired pause
results in a freeze. However the requirements for the freeze may be very
difficult to meet, thus the bug remains unproven.
[1] https://bugzilla.gnome.org/show_bug.cgi?id=719883
[2] https://bugzilla.gnome.org/show_bug.cgi?id=702392
THE PATCH for Emacs
Emacs is not free of bugs in this area. I consider a bug the behaviour,
when inside a gtk signal handler (scroll bar event) we enter another gtk
event loop.
That's because of (almost) undocumented feature of unblock_input. It
does not only process the events that came during block/unblock pair,
but it also processes the queue of events that were not processed
before. Emacs seems to rely on calls to ublock_input, which trigger
reading the input. A function without block/unblock statements would
actually be never interrupted. When block/unblock pair is inserted, it
will cause input handling at the moment of unblock_input call. That does
not hurt much, as stated by Stephan in [3], but introduces a
counter-intuitive feature: the function containing block/unblock is
usually safer than the one not containing them. It is most important in
callbacks. A callback containing block/unblock is unsafe, unless it is
contained in an outer block/unblock pair.
The patch introduces block/unblock input wrapper around the glib main
loop in xgselect.c, thus preventing main loop recursion. The recursion
was occuring when unblock_input was called inside the scroll bar
callback. Full backtrace attached.
This time I believe the patch is something that should be applied. It
contains also comments, that should make some features better noticable.
One of the comments is for unblock_input. I hope it's agreeable.
Jarek
[3]
http://emacs.1067599.n5.nabble.com/GTK-stack-busting-loop-tp219788p219791.html
[-- Attachment #2: reent_bt.txt --]
[-- Type: text/plain, Size: 13736 bytes --]
Script started on Sat 07 Dec 2013 10:43:18 AM CET
jcdeb:/m/usr/src/gtk+# gdb\b \b\b \b\b \bbs=1 gdb --args emacs -Q
GNU gdb (GDB) 7.6.1 (Debian 7.6.1-1)
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/local/bin/emacs-24.3.50...done.
(gdb) start
Temporary breakpoint 1 at 0x80582f0: file ../../emacs-checkout/src/emacs.c, line 688.
Starting program: /usr/local/bin/emacs -Q
warning: Could not load shared library symbols for linux-gate.so.1.
Do you need "set solib-search-path" or "set sysroot"?
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/i686/cmov/libthread_db.so.1".
Temporary breakpoint 1, main (argc=2, argv=0xbffff554)
at ../../emacs-checkout/src/emacs.c:688
688 {
(gdb) break gdkframeclockidle.c:329 if bsnested>1
Breakpoint 2 at 0xb78f59bf: file gdkframeclockidle.c, line 329.
(gdb) cont
Continuing.
[New Thread 0xb5f2db40 (LWP 17607)]
<[New Thread 0xb5554b40 (LWP 17609)]
[New Thread 0xb4bffb40 (LWP 17611)]
<m<>>mPmmmpmmmPmpmmmPpmmmP<p<m>mPmmmpmmPmp<m>mPmpmmmmPpmmPmmpmmmmPpm<m'mF'@mf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mF'@m'@mf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}mmPpm'mF'@mf(0mP{m)p}m'mF'@mf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}mmP'mF'@mf(0{m)p}mmP'mFpmf(0mP{m)p}m'mF'@mf(0mP{m)p}m'mF'@m'@mf(0mP{m)p}m'mF'@m'@mf(0mP{m)p}m'mFmP'@mf(0pmPpm'mF{mP)mfp}mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0mP{m)p}m'mF'@m'@mf(0mP{m)p}m'mFmP'@mf(0{m)p}m'mF'@m'@mf(0mP{m)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mF'@mf(0mP{m)p}m'mF'@mf(0mP{m)p}m'mF'@mf(0mP{m)p}mmP'mFf(0pmPpm{mP)mp}m'mF'@m'@m'@mf(0'mFmPfpmFPf(1$
Breakpoint 2, gdk_frame_clock_flush_idle (data=0x85e4950)
at gdkframeclockidle.c:329
329 g_signal_emit_by_name (G_OBJECT (clock), "flush-events");
(gdb) bt
#0 gdk_frame_clock_flush_idle (data=0x85e4950) at gdkframeclockidle.c:329
#1 0xb78e7075 in gdk_threads_dispatch (data=data@entry=0x8a13230) at gdk.c:788
#2 0xb74810b1 in g_timeout_dispatch (source=source@entry=0x8a70ef0,
callback=0xb78e7040 <gdk_threads_dispatch>, user_data=0x8a13230)
at /build/glib2.0-Ot8bbC/glib2.0-2.36.4/./glib/gmain.c:4413
#3 0xb748042e in g_main_dispatch (context=0x85cd918, context@entry=0x85bd9a0)
at /build/glib2.0-Ot8bbC/glib2.0-2.36.4/./glib/gmain.c:3054
#4 g_main_context_dispatch (context=context@entry=0x85cd918)
at /build/glib2.0-Ot8bbC/glib2.0-2.36.4/./glib/gmain.c:3630
#5 0xb74807d8 in g_main_context_iterate (context=context@entry=0x85cd918,
block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>)
at /build/glib2.0-Ot8bbC/glib2.0-2.36.4/./glib/gmain.c:3701
#6 0xb7480898 in g_main_context_iteration (context=0x85cd918,
context@entry=0x0, may_block=may_block@entry=1)
at /build/glib2.0-Ot8bbC/glib2.0-2.36.4/./glib/gmain.c:3762
#7 0xb7aedbd8 in gtk_main_iteration () at gtkmain.c:1260
#8 0x080f13a1 in XTread_socket (terminal=0x8773c10, hold_quit=0xbfffdc9c)
at ../../emacs-checkout/src/xterm.c:7077
#9 0x08125329 in gobble_input () at ../../emacs-checkout/src/keyboard.c:6841
#10 0x08124d05 in handle_async_input ()
at ../../emacs-checkout/src/keyboard.c:7081
#11 process_pending_signals () at ../../emacs-checkout/src/keyboard.c:7095
#12 0x081264e3 in unblock_input () at ../../emacs-checkout/src/keyboard.c:7124
---Type <return> to continue, or q <return> to quit---
#13 0x080eeca8 in x_send_scroll_bar_event (window=<optimized out>,
part=<optimized out>, portion=<optimized out>, whole=whole@entry=1617275)
at ../../emacs-checkout/src/xterm.c:4299
#14 0x080f0832 in xg_scroll_callback (range=range@entry=0x84c8220,
scroll=GTK_SCROLL_JUMP, value=value@entry=1980707.359550562,
user_data=user_data@entry=0x8a06838)
at ../../emacs-checkout/src/xterm.c:4472
#15 0xb7aef2f3 in _gtk_marshal_BOOLEAN__ENUM_DOUBLE (closure=0x8a1f458,
return_value=0xbfffdee0, n_param_values=3, param_values=0xbfffdf50,
invocation_hint=0xbfffdefc, marshal_data=0x0) at gtkmarshalers.c:442
#16 0xb754b69e in g_closure_invoke (closure=0x8a1f458,
return_value=return_value@entry=0xbfffdee0, n_param_values=3,
param_values=param_values@entry=0xbfffdf50,
invocation_hint=invocation_hint@entry=0xbfffdefc)
at /build/glib2.0-Ot8bbC/glib2.0-2.36.4/./gobject/gclosure.c:777
#17 0xb755d149 in signal_emit_unlocked_R (node=node@entry=0x84c5cc8, detail=0,
instance=0x84c8220, emission_return=emission_return@entry=0xbfffe010,
instance_and_params=0xbfffdf50)
at /build/glib2.0-Ot8bbC/glib2.0-2.36.4/./gobject/gsignal.c:3584
#18 0xb7564884 in g_signal_emit_valist (instance=instance@entry=0x84c8220,
signal_id=signal_id@entry=152, detail=detail@entry=0,
var_args=0xbfffe0c8 "üàÿ¿\230u÷", var_args@entry=0xbfffe0bc "\001")
at /build/glib2.0-Ot8bbC/glib2.0-2.36.4/./gobject/gsignal.c:3338
---Type <return> to continue, or q <return> to quit---
#19 0xb7564dd3 in g_signal_emit (instance=instance@entry=0x84c8220,
signal_id=152, detail=detail@entry=0)
at /build/glib2.0-Ot8bbC/glib2.0-2.36.4/./gobject/gsignal.c:3384
#20 0xb7b3f62a in update_slider_position (range=range@entry=0x84c8220,
mouse_x=<optimized out>, mouse_y=299) at gtkrange.c:2746
#21 0xb7b3fa4e in gtk_range_motion_notify (widget=0x84c8220, event=0x8519770)
at gtkrange.c:2911
#22 0xb7aeec16 in _gtk_marshal_BOOLEAN__BOXEDv (closure=0x85bc6a8,
return_value=0xbfffe268, instance=0x84c8220,
args=0xbfffe33c "p\227Q\b\\ãÿ¿\020\227[\b\200dL\bh\017æ·çÒ·h\017æ· \202L\b", marshal_data=0xb7b3f990 <gtk_range_motion_notify>, n_params=1,
param_types=0x85bbdc8) at gtkmarshalers.c:130
#23 0xb754a077 in g_type_class_meta_marshalv (closure=0x85bc6a8,
return_value=0xbfffe268, instance=0x84c8220,
args=0xbfffe33c "p\227Q\b\\ãÿ¿\020\227[\b\200dL\bh\017æ·çÒ·h\017æ· \202L\b", marshal_data=0xcc, n_params=1, param_types=0x85bbdc8)
at /build/glib2.0-Ot8bbC/glib2.0-2.36.4/./gobject/gclosure.c:997
#24 0xb754b8de in _g_closure_invoke_va (closure=closure@entry=0x85bc6a8,
return_value=return_value@entry=0xbfffe268,
instance=instance@entry=0x84c8220,
args=args@entry=0xbfffe33c "p\227Q\b\\ãÿ¿\020\227[\b\200dL\bh\017æ·çÒ·h\017æ· \202L\b", n_params=1, param_types=0x85bbdc8)
at /build/glib2.0-Ot8bbC/glib2.0-2.36.4/./gobject/gclosure.c:840
---Type <return> to continue, or q <return> to quit---
#25 0xb7564237 in g_signal_emit_valist (instance=instance@entry=0x84c8220,
signal_id=signal_id@entry=32, detail=detail@entry=0,
var_args=var_args@entry=0xbfffe33c "p\227Q\b\\ãÿ¿\020\227[\b\200dL\bh\017æ·çÒ·h\017æ· \202L\b")
at /build/glib2.0-Ot8bbC/glib2.0-2.36.4/./gobject/gsignal.c:3234
#26 0xb7564dd3 in g_signal_emit (instance=instance@entry=0x84c8220,
signal_id=32, detail=detail@entry=0)
at /build/glib2.0-Ot8bbC/glib2.0-2.36.4/./gobject/gsignal.c:3384
#27 0xb7c2d8fb in gtk_widget_event_internal (widget=widget@entry=0x84c8220,
event=event@entry=0x8519770) at gtkwidget.c:6722
#28 0xb7c2dbd5 in gtk_widget_event (widget=widget@entry=0x84c8220,
event=event@entry=0x8519770) at gtkwidget.c:6379
#29 0xb7aeca25 in propagate_event_up (topmost=<optimized out>,
event=<optimized out>, widget=0x84c8220) at gtkmain.c:2393
#30 propagate_event (widget=<optimized out>, event=0x8519770, captured=0,
topmost=0x0) at gtkmain.c:2501
#31 0xb7aee810 in gtk_main_do_event (event=0x8519770) at gtkmain.c:1716
#32 0xb78f052c in _gdk_event_emit (event=event@entry=0x8519770)
at gdkevents.c:71
#33 0xb78ef0f8 in _gdk_display_flush_events (display=display@entry=0x85dc040)
at gdkdisplay.c:2039
#34 0xb78fbec6 in gdk_window_flush_events (clock=0x85e4950, data=0x85e2980)
at gdkwindow.c:11610
---Type <return> to continue, or q <return> to quit---
#35 0xb754d339 in g_cclosure_marshal_VOID__VOIDv (closure=0x853a2f8,
return_value=0x0, instance=0x85e4950, args=0xbfffe6b8 "\001",
marshal_data=0x0, n_params=0, param_types=0x0)
at /build/glib2.0-Ot8bbC/glib2.0-2.36.4/./gobject/gmarshal.c:115
#36 0xb754b8de in _g_closure_invoke_va (closure=closure@entry=0x853a2f8,
return_value=return_value@entry=0x0, instance=instance@entry=0x85e4950,
args=args@entry=0xbfffe6b8 "\001", n_params=0, param_types=0x0)
at /build/glib2.0-Ot8bbC/glib2.0-2.36.4/./gobject/gclosure.c:840
#37 0xb7564237 in g_signal_emit_valist (instance=instance@entry=0x85e4950,
signal_id=signal_id@entry=136, detail=detail@entry=0,
var_args=var_args@entry=0xbfffe6b8 "\001")
at /build/glib2.0-Ot8bbC/glib2.0-2.36.4/./gobject/gsignal.c:3234
#38 0xb7565291 in g_signal_emit_by_name (instance=instance@entry=0x85e4950,
detailed_signal=detailed_signal@entry=0xb7934e13 "flush-events")
at /build/glib2.0-Ot8bbC/glib2.0-2.36.4/./gobject/gsignal.c:3424
#39 0xb78f59d1 in gdk_frame_clock_flush_idle (data=0x85e4950)
at gdkframeclockidle.c:329
#40 0xb78e7075 in gdk_threads_dispatch (data=data@entry=0x8a13390) at gdk.c:788
#41 0xb74810b1 in g_timeout_dispatch (source=source@entry=0x85550c0,
callback=0xb78e7040 <gdk_threads_dispatch>, user_data=0x8a13390)
at /build/glib2.0-Ot8bbC/glib2.0-2.36.4/./glib/gmain.c:4413
#42 0xb748042e in g_main_dispatch (context=0x85cd918, context@entry=0xb753c000)
at /build/glib2.0-Ot8bbC/glib2.0-2.36.4/./glib/gmain.c:3054
---Type <return> to continue, or q <return> to quit---
#43 g_main_context_dispatch (context=context@entry=0x85cd918)
at /build/glib2.0-Ot8bbC/glib2.0-2.36.4/./glib/gmain.c:3630
#44 0x081ff178 in xg_select (fds_lim=<optimized out>, rfds=0xbfffed70,
wfds=0xbfffedf0, efds=0x0, timeout=0xbfffe7c8, sigmask=0x0)
at ../../emacs-checkout/src/xgselect.c:147
#45 0x081cb30b in wait_reading_process_output (time_limit=<optimized out>,
nsecs=0, read_kbd=read_kbd@entry=-1, do_display=do_display@entry=true,
wait_for_cell=138861506, wait_proc=wait_proc@entry=0x0,
just_wait_proc=just_wait_proc@entry=0)
at ../../emacs-checkout/src/process.c:4584
#46 0x08062595 in sit_for (timeout=timeout@entry=120,
reading=reading@entry=true, display_option=display_option@entry=1)
at ../../emacs-checkout/src/dispnew.c:5800
#47 0x081292a6 in read_char (commandflag=1, map=map@entry=142392614,
prev_event=138861506, used_mouse_menu=used_mouse_menu@entry=0xbffff25b,
end_time=end_time@entry=0x0) at ../../emacs-checkout/src/keyboard.c:2805
#48 0x0812a8a8 in read_key_sequence (keybuf=keybuf@entry=0xbffff308,
prompt=138861506, dont_downcase_last=false, dont_downcase_last@entry=10,
can_return_switch_frame=can_return_switch_frame@entry=true,
fix_current_buffer=fix_current_buffer@entry=true, prevent_redisplay=false,
prevent_redisplay@entry=10, bufsize=30)
at ../../emacs-checkout/src/keyboard.c:9074
#49 0x0812b9d6 in command_loop_1 () at ../../emacs-checkout/src/keyboard.c:1445
---Type <return> to continue, or q <return> to quit---
#50 0x0818d3aa in internal_condition_case (
bfun=bfun@entry=0x812b820 <command_loop_1>, handlers=138894602,
hfun=hfun@entry=0x8123260 <cmd_error>)
at ../../emacs-checkout/src/eval.c:1344
#51 0x08121515 in command_loop_2 (ignore=ignore@entry=138861506)
at ../../emacs-checkout/src/keyboard.c:1170
#52 0x0818d2cd in internal_catch (tag=138892650,
func=func@entry=0x81214f0 <command_loop_2>, arg=138861506)
at ../../emacs-checkout/src/eval.c:1108
#53 0x08122e72 in command_loop () at ../../emacs-checkout/src/keyboard.c:1149
#54 recursive_edit_1 () at ../../emacs-checkout/src/keyboard.c:777
#55 0x0812314b in Frecursive_edit () at ../../emacs-checkout/src/keyboard.c:841
#56 0x08058e28 in main (argc=<optimized out>, argv=0xbffff554)
at ../../emacs-checkout/src/emacs.c:1598
(gdb) quit
A debugging session is active.
Inferior 1 [process 17567] will be killed.
Quit anyway? (y or n) y
jcdeb:/m/usr/src/gtk+# exit
exit
Script done on Sat 07 Dec 2013 10:44:12 AM CET
[-- Attachment #3: scroll_freeze_2_0.txt --]
[-- Type: text/plain, Size: 3623 bytes --]
=== modified file 'src/ChangeLog'
*** src/ChangeLog 2013-12-08 08:05:36 +0000
--- src/ChangeLog 2013-12-08 16:00:41 +0000
***************
*** 1,3 ****
--- 1,9 ----
+ 2013-12-08 Jarek Czekalski <jarekczek@poczta.onet.pl>
+
+ Fix freezing with scroll bars of GTK3 Toolkit (Bug#15801).
+ * keyboard.c: A comment to unblock_input.
+ * xgselect.c: Prevent Glib main loop recursion.
+
2013-12-08 Paul Eggert <eggert@cs.ucla.edu>
Use libcrypto's checksum implementations if available, for speed.
=== modified file 'src/keyboard.c'
*** src/keyboard.c 2013-12-07 23:04:10 +0000
--- src/keyboard.c 2013-12-08 15:20:00 +0000
*************** unblock_input_to (int level)
*** 7118,7124 ****
/* End critical section.
If doing signal-driven input, and a signal came in when input was
! blocked, reinvoke the signal handler now to deal with it. */
void
unblock_input (void)
--- 7118,7129 ----
/* End critical section.
If doing signal-driven input, and a signal came in when input was
! blocked, reinvoke the signal handler now to deal with it.
!
! It will also process queued input, if it was not read before.
! When a longer code sequence does not use block/unblock input
! at all, the whole input gathered up to the next call to
! unblock_input will be processed inside that call. */
void
unblock_input (void)
=== modified file 'src/xgselect.c'
*** src/xgselect.c 2013-08-27 19:36:28 +0000
--- src/xgselect.c 2013-12-08 15:52:28 +0000
*************** along with GNU Emacs. If not, see <http
*** 28,33 ****
--- 28,44 ----
#include <timespec.h>
#include "frame.h"
+ /* xg_select is a pselect replacement. Why do we need a separate function?
+ 1. Timeouts. Glib and Gtk rely on timer events. If we did pselect
+ with a greater timeout then the one scheduled by Glib, we would
+ not allow Glib to process its timer events. We want Glib to
+ work smoothly, so we need to reduce our timeout to match Glib.
+ 2. Descriptors. Glib may listen to more file descriptors than we do.
+ So we add Glib descriptors to our pselect pool, but we don't change
+ the value returned by the function. The return value matches only
+ the descriptors passed as arguments, making it compatible with
+ plain pselect. */
+
int
xg_select (int fds_lim, fd_set *rfds, fd_set *wfds, fd_set *efds,
struct timespec const *timeout, sigset_t const *sigmask)
*************** xg_select (int fds_lim, fd_set *rfds, fd
*** 45,56 ****
int i, nfds, tmo_in_millisec;
USE_SAFE_ALLOCA;
- /* Do not try to optimize with an initial check with g_main_context_pending
- and a call to pselect if it returns false. If Gdk has a timeout for 0.01
- second, and Emacs has a timeout for 1 second, g_main_context_pending will
- return false, but the timeout will be 1 second, thus missing the gdk
- timeout with a lot. */
-
context = g_main_context_default ();
if (rfds) all_rfds = *rfds;
--- 56,61 ----
*************** xg_select (int fds_lim, fd_set *rfds, fd
*** 132,139 ****
--- 137,149 ----
#ifdef USE_GTK
if (retval == 0)
#endif
+ /* Prevent g_main_dispatch recursion, that would occur without
+ block_input wrapper, because event handlers call
+ unblock_input. Event loop recursion was causing Bug#15801. */
+ block_input();
while (g_main_context_pending (context))
g_main_context_dispatch (context);
+ unblock_input();
/* To not have to recalculate timeout, return like this. */
if (retval == 0)
^ permalink raw reply [flat|nested] 32+ messages in thread* bug#15801: 24.3.50; bar scrolling freezes gtk emacs
2013-11-04 18:42 bug#15801: 24.3.50; bar scrolling freezes gtk emacs Jarek Czekalski
` (9 preceding siblings ...)
2013-12-08 16:14 ` Jarek Czekalski
@ 2013-12-08 23:29 ` Jarek Czekalski
2013-12-11 19:52 ` Jan Djärv
2013-12-20 6:32 ` Jarek Czekalski
2014-04-21 10:34 ` Jarek Czekalski
11 siblings, 2 replies; 32+ messages in thread
From: Jarek Czekalski @ 2013-12-08 23:29 UTC (permalink / raw)
To: 15801
[-- Attachment #1: Type: text/plain, Size: 72 bytes --]
Fixing compilation warning in the patch, missing include blockinput.h.
[-- Attachment #2: scroll_freeze_2_1.txt --]
[-- Type: text/plain, Size: 3607 bytes --]
=== modified file 'src/ChangeLog'
*** src/ChangeLog 2013-12-08 08:05:36 +0000
--- src/ChangeLog 2013-12-08 16:00:41 +0000
***************
*** 1,3 ****
--- 1,9 ----
+ 2013-12-08 Jarek Czekalski <jarekczek@poczta.onet.pl>
+
+ Fix freezing with scroll bars of GTK3 Toolkit (Bug#15801).
+ * keyboard.c: A comment to unblock_input.
+ * xgselect.c: Prevent Glib main loop recursion.
+
2013-12-08 Paul Eggert <eggert@cs.ucla.edu>
Use libcrypto's checksum implementations if available, for speed.
=== modified file 'src/keyboard.c'
*** src/keyboard.c 2013-12-07 23:04:10 +0000
--- src/keyboard.c 2013-12-08 15:20:00 +0000
*************** unblock_input_to (int level)
*** 7118,7124 ****
/* End critical section.
If doing signal-driven input, and a signal came in when input was
! blocked, reinvoke the signal handler now to deal with it. */
void
unblock_input (void)
--- 7118,7129 ----
/* End critical section.
If doing signal-driven input, and a signal came in when input was
! blocked, reinvoke the signal handler now to deal with it.
!
! It will also process queued input, if it was not read before.
! When a longer code sequence does not use block/unblock input
! at all, the whole input gathered up to the next call to
! unblock_input will be processed inside that call. */
void
unblock_input (void)
=== modified file 'src/xgselect.c'
*** src/xgselect.c 2013-08-27 19:36:28 +0000
--- src/xgselect.c 2013-12-08 22:54:04 +0000
*************** along with GNU Emacs. If not, see <http
*** 27,32 ****
--- 27,44 ----
#include <errno.h>
#include <timespec.h>
#include "frame.h"
+ #include "blockinput.h"
+
+ /* xg_select is a pselect replacement. Why do we need a separate function?
+ 1. Timeouts. Glib and Gtk rely on timer events. If we did pselect
+ with a greater timeout then the one scheduled by Glib, we would
+ not allow Glib to process its timer events. We want Glib to
+ work smoothly, so we need to reduce our timeout to match Glib.
+ 2. Descriptors. Glib may listen to more file descriptors than we do.
+ So we add Glib descriptors to our pselect pool, but we don't change
+ the value returned by the function. The return value matches only
+ the descriptors passed as arguments, making it compatible with
+ plain pselect. */
int
xg_select (int fds_lim, fd_set *rfds, fd_set *wfds, fd_set *efds,
*************** xg_select (int fds_lim, fd_set *rfds, fd
*** 45,56 ****
int i, nfds, tmo_in_millisec;
USE_SAFE_ALLOCA;
- /* Do not try to optimize with an initial check with g_main_context_pending
- and a call to pselect if it returns false. If Gdk has a timeout for 0.01
- second, and Emacs has a timeout for 1 second, g_main_context_pending will
- return false, but the timeout will be 1 second, thus missing the gdk
- timeout with a lot. */
-
context = g_main_context_default ();
if (rfds) all_rfds = *rfds;
--- 57,62 ----
*************** xg_select (int fds_lim, fd_set *rfds, fd
*** 132,139 ****
--- 138,150 ----
#ifdef USE_GTK
if (retval == 0)
#endif
+ /* Prevent g_main_dispatch recursion, that would occur without
+ block_input wrapper, because event handlers call
+ unblock_input. Event loop recursion was causing Bug#15801. */
+ block_input();
while (g_main_context_pending (context))
g_main_context_dispatch (context);
+ unblock_input();
/* To not have to recalculate timeout, return like this. */
if (retval == 0)
^ permalink raw reply [flat|nested] 32+ messages in thread* bug#15801: 24.3.50; bar scrolling freezes gtk emacs
2013-11-04 18:42 bug#15801: 24.3.50; bar scrolling freezes gtk emacs Jarek Czekalski
` (10 preceding siblings ...)
2013-12-08 23:29 ` Jarek Czekalski
@ 2014-04-21 10:34 ` Jarek Czekalski
2014-04-21 15:56 ` Stefan Monnier
11 siblings, 1 reply; 32+ messages in thread
From: Jarek Czekalski @ 2014-04-21 10:34 UTC (permalink / raw)
To: 15801
[-- Attachment #1: Type: text/plain, Size: 27 bytes --]
Patch rebased for r117003.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: scroll_freeze_2_1_r117003.patch --]
[-- Type: text/x-diff; name="scroll_freeze_2_1_r117003.patch", Size: 3685 bytes --]
=== modified file 'src/ChangeLog'
*** src/ChangeLog 2014-04-19 20:32:05 +0000
--- src/ChangeLog 2014-04-21 10:32:13 +0000
***************
*** 2448,2453 ****
--- 2448,2459 ----
* alloc.c (Fmemory_limit): Avoid compiler warning. Return 0 always.
+ 2013-12-08 Jarek Czekalski <jarekczek@poczta.onet.pl>
+
+ Fix freezing with scroll bars of GTK3 Toolkit (Bug#15801).
+ * keyboard.c: A comment to unblock_input.
+ * xgselect.c: Prevent Glib main loop recursion.
+
2013-12-08 Jan Djärv <jan.h.d@swipnet.se>
* nsterm.m (updateFrameSize:): Fix GNUstep toolbar not updating.
=== modified file 'src/keyboard.c'
*** src/keyboard.c 2014-04-16 19:43:46 +0000
--- src/keyboard.c 2014-04-21 10:32:13 +0000
***************
*** 7117,7123 ****
/* End critical section.
If doing signal-driven input, and a signal came in when input was
! blocked, reinvoke the signal handler now to deal with it. */
void
unblock_input (void)
--- 7117,7128 ----
/* End critical section.
If doing signal-driven input, and a signal came in when input was
! blocked, reinvoke the signal handler now to deal with it.
!
! It will also process queued input, if it was not read before.
! When a longer code sequence does not use block/unblock input
! at all, the whole input gathered up to the next call to
! unblock_input will be processed inside that call. */
void
unblock_input (void)
=== modified file 'src/xgselect.c'
*** src/xgselect.c 2014-04-16 19:43:46 +0000
--- src/xgselect.c 2014-04-21 10:32:13 +0000
***************
*** 28,33 ****
--- 28,45 ----
#include <stdbool.h>
#include <timespec.h>
#include "frame.h"
+ #include "blockinput.h"
+
+ /* xg_select is a pselect replacement. Why do we need a separate function?
+ 1. Timeouts. Glib and Gtk rely on timer events. If we did pselect
+ with a greater timeout then the one scheduled by Glib, we would
+ not allow Glib to process its timer events. We want Glib to
+ work smoothly, so we need to reduce our timeout to match Glib.
+ 2. Descriptors. Glib may listen to more file descriptors than we do.
+ So we add Glib descriptors to our pselect pool, but we don't change
+ the value returned by the function. The return value matches only
+ the descriptors passed as arguments, making it compatible with
+ plain pselect. */
int
xg_select (int fds_lim, fd_set *rfds, fd_set *wfds, fd_set *efds,
***************
*** 47,58 ****
bool need_to_dispatch;
USE_SAFE_ALLOCA;
- /* Do not try to optimize with an initial check with g_main_context_pending
- and a call to pselect if it returns false. If Gdk has a timeout for 0.01
- second, and Emacs has a timeout for 1 second, g_main_context_pending will
- return false, but the timeout will be 1 second, thus missing the gdk
- timeout with a lot. */
-
context = g_main_context_default ();
if (rfds) all_rfds = *rfds;
--- 59,64 ----
***************
*** 136,143 ****
if (need_to_dispatch)
{
int pselect_errno = errno;
while (g_main_context_pending (context))
! g_main_context_dispatch (context);
errno = pselect_errno;
}
--- 142,154 ----
if (need_to_dispatch)
{
int pselect_errno = errno;
+ /* Prevent g_main_dispatch recursion, that would occur without
+ block_input wrapper, because event handlers call
+ unblock_input. Event loop recursion was causing Bug#15801. */
+ block_input();
while (g_main_context_pending (context))
! g_main_context_dispatch (context);
! unblock_input();
errno = pselect_errno;
}
^ permalink raw reply [flat|nested] 32+ messages in thread