ratpoison-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RP] window numbering bug/race?


From: Joshua Neuheisel
Subject: Re: [RP] window numbering bug/race?
Date: Fri, 25 Nov 2005 21:52:30 -0500

On 11/23/05, address@hidden <address@hidden> wrote:
"ratpoison -c windows" shows that I have 12 windows, two of which are
numbered "10".  If I select window 9 and go "next", I get one of
them; if I select 0 and go "prev", I get the other.  One is an xterm,
the other is a dclock; they were all started sequentially using
xtoolwait (thus rapidly, but in a well defined order.)

First noticed it with 1.3.0-7 under ubuntu; that doesn't mean it
wasn't happening under debian, but I hadn't *noticed* it there.  Built
from CVS a few days ago, with the latest ChangeLog entry being
2005-11-05, and it still happens the same way.


Alright, I think I have some new info here.  I was able to reliably reproduce the problem on MacOS X Tiger with gcc version as such:
powerpc-apple-darwin8-gcc-4.0.0 (GCC) 4.0.0 20041026 (Apple Computer, Inc. build 4061)

To fix it, I changed line 79 in src/number.c from

ns->numbers_taken[numset_find_empty_cell(ns)] = n;

to

int ec;
ec = numset_find_empty_cell(ns);
ns->numbers_taken[ec] = n;

and the problem went away.  When I stepped through the code, I saw that the return value from numset_find_empty_cell was being discarded, and the assigment was being ignored.  Obviously, this is a compiler error.  I was not able to reproduce it on my i686/linux machine running gcc version:
gcc (GCC) 3.4.5 20051026 (prerelease).
I was also not able to reproduce it on my MacOS X with the gcc-3.3 version:
gcc-3.3 (GCC) 3.3 20030304 (Apple Computer, Inc. build 1809).

What gcc version did the original poster use?  Or was it another compiler?

Joshua


reply via email to

[Prev in Thread] Current Thread [Next in Thread]