unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: "Jan Djärv" <jan.h.d@swipnet.se>
To: Jarek Czekalski <jarekczek@poczta.onet.pl>
Cc: 15801@debbugs.gnu.org
Subject: bug#15801: 24.3.50; bar scrolling freezes gtk emacs
Date: Sun, 1 Dec 2013 00:16:52 +0100	[thread overview]
Message-ID: <2C9F6FFF-8FAD-42BC-81A5-723D6E4983FD@swipnet.se> (raw)
In-Reply-To: <529A1A85.6050608@poczta.onet.pl>

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.






  reply	other threads:[~2013-11-30 23:16 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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-21  6:00   ` Jan Djärv
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
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
2013-11-30 18:38                 ` Eli Zaretskii
2013-11-30 17:04 ` Jarek Czekalski
2013-11-30 23:16   ` Jan Djärv [this message]
     [not found]     ` <529AF507.5080509@poczta.onet.pl>
     [not found]       ` <0440E2A5-37C6-4F29-9B5D-38A6AE88C3B5@swipnet.se>
     [not found]         ` <529B12DB.6020407@poczta.onet.pl>
2013-12-01 11:07           ` Jan Djärv
2013-12-01 11:38             ` Jarek Czekalski
2013-12-01 11:48               ` Jan Djärv
2013-11-30 17:10 ` bug#15801: 24.3.50; bar scrolling freezes gtk emacs - stdout warning Jarek Czekalski
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
2013-12-03 22:27 ` Jarek Czekalski
2013-12-04 20:28 ` Jarek Czekalski
2013-12-05 17:08   ` Jarek Czekalski
2013-12-07 14:34     ` Jan Djärv
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
2013-12-20  8:58     ` Eli Zaretskii
2014-04-21 10:34 ` Jarek Czekalski
2014-04-21 15:56   ` Stefan Monnier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2C9F6FFF-8FAD-42BC-81A5-723D6E4983FD@swipnet.se \
    --to=jan.h.d@swipnet.se \
    --cc=15801@debbugs.gnu.org \
    --cc=jarekczek@poczta.onet.pl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).