[Rd] misbehaviour of some tk windows, R 2.6.0 on SUSE 10.1?

[Peter Dalgaard]

Peter Dalgaard wrote:
> David Firth wrote:
>   
>> I don't know whether this is specific to (my installation 
>> of) SUSE 10.1, or is more general.  
>>
>> With R 2.6.0, I am finding that some widgets made through 
>> the tcltk package are having problems which become evident 
>> through scrollbar activity.  An example is demo(tkfaq) -- 
>> see below.  To reproduce the problem, I do the following: 
>> after the tk window appears, hold down the "scroll-down" 
>> tab at the foot of the window for a few seconds, then 
>> release.  If scrolling stops (as it should, if all is 
>> working correctly), do the same thing again.  Repeating 
>> this 2 or 3 times usually results in uncontrolled 
>> (unstoppable) scrolling activity; and closing the window 
>> when that happens delivers the errors that appear in the 
>> transcript below.
>>
>> My R 2.6.0 was built on my own system,
>>
>> OS:  SUSE linux 10.1
>> tcl: 8.4.12-14
>> tk:  8.4.12-14
>> gcc: 4.1.0-25
>>
>> Since I had not seen this behaviour with previous versions 
>> of R, I did a check with R 2.5.1: a fresh build today of R 
>> 2.5.1 on the same system does not appear to have the same 
>> problem.
>>
>> Any ideas?  Is anyone else seeing this behaviour?
>>
>> David
>>   
>>     
>
> Looks a bit nasty. I see it on SUSE 10.2 as well. Increasing the
> repeatinterval setting for the scrollbar helps, but even at a setting of
> 50, I still see the effect. It is usually stoppable with the middle
> button over the trough.
> The error message is what you'd expect from killing a window while
> something is trying to talk to widgets inside of it. The details of the
> popup dialog is a little more informative:
>
>     while executing
> "$w cget -repeatinterval"
>     (procedure "tk::ScrollSelect" line 12)
>     invoked from within
> "tk::ScrollSelect .3.2 arrow2 again"
>     ("after" script)
>
> I think there's a clue in there. It has the hallmarks of a race
> condition: As I understand it the autorepeat feature runs an "after"
> script which effectively presses the arrow again 5 ms later, invoking
> another "after" script, etc. A button release is supposed to kill the
> after script, but it might not do so in time, in which case it may try
> to kill something that already died, etc.
>
> Can't offhand see that we did anything to the event loop that could
> cause this, though.
>   
Exactly the same behaviour on Fedora 7. Looping scrolling with 2.6.0+, 
no probs with 2.5.1.

Can probably eliminate OS issues and hardware then (2x3.2GHz, 64 bit 
SUSE vs. 600MHz, 32bit Fedora).  Argh....

-- 
   O__  ---- Peter Dalgaard             Øster Farimagsgade 5, Entr.B
  c/ /'_ --- Dept. of Biostatistics     PO Box 2099, 1014 Cph. K
 (*) \(*) -- University of Copenhagen   Denmark          Ph:  (+45) 35327918
~~~~~~~~~~ - (p.dalgaard at biostat.ku.dk)                  FAX: (+45) 35327907