GNU bug report logs - #15801
24.3.50; bar scrolling freezes gtk emacs

Previous Next

Full log

Message #47 received at 15801 <at> debbugs.gnu.org (full text, mbox):

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Jarek Czekalski <jarekczek <at> poczta.onet.pl>
Cc: 15801 <at> debbugs.gnu.org
Subject: Re: bug#15801: 24.3.50; bar scrolling freezes gtk emacs
Date: Sun, 1 Dec 2013 00:16:52 +0100

Hello.

30 nov 2013 kl. 18:04 skrev Jarek Czekalski <jarekczek <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.