From: SourceForge.net <no...@so...> - 2005-03-15 23:42:55
|
Bugs item #1143776, was opened at 2005-02-18 05:11 Message generated for change (Comment added) made by revar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=112997&aid=1143776&group_id=12997 Category: 18. [text] Group: development: 8.5a3 Status: Open Resolution: Fixed Priority: 8 Submitted By: Neil Madden (tallniel) Assigned to: Vince Darley (vincentdarley) Summary: Panic: Added too many new lines in UpdateDisplayInfo Initial Comment: The current cvs head contains a bug in the text widget that causes a panic with the message "Added too many new lines in UpdateDisplayInfo". I can reproduce this consitently on Linux, using Donal's text justification demo: http://www.man.ac.uk/~zzcgudf/tcl/wordwrap.tcl Run the demo in wish and then move the scrollbar on the text widget to show the last line - this causes the panic for me. Basic stack trace: (gdb) bt #0 0x403b5d71 in kill () from /lib/i686/libc.so.6 #1 0x403b5af5 in raise () from /lib/i686/libc.so.6 #2 0x403b71e0 in abort () from /lib/i686/libc.so.6 #3 0x401754d8 in Tcl_PanicVA () from /usr/local/lib/libtcl8.5.so #4 0x40175500 in Tcl_Panic () from /usr/local/lib/libtcl8.5.so #5 0x400c6129 in UpdateDisplayInfo () from /usr/local/lib/libtk8.5.so #6 0x400cb2be in TkTextPixelIndex () from /usr/local/lib/libtk8.5.so #7 0x400d2d8b in TkTextPickCurrent () from /usr/local/lib/libtk8.5.so #8 0x400c83a6 in DisplayText () from /usr/local/lib/libtk8.5.so #9 0x401891ba in TclServiceIdle () from /usr/local/lib/libtcl8.5.so #10 0x40172f96 in Tcl_DoOneEvent () from /usr/local/lib/libtcl8.5.so #11 0x4003cd7d in Tk_MainLoop () from /usr/local/lib/libtk8.5.so #12 0x400494af in Tk_MainEx () from /usr/local/lib/libtk8.5.so #13 0x0804886e in main () #14 0x403a2c57 in __libc_start_main () from /lib/i686/libc.so.6 ---------------------------------------------------------------------- Comment By: Revar (revar) Date: 2005-03-15 15:42 Message: Logged In: YES user_id=6331 At least it crashes in TkAqua standalone for me. It doesn't seem to in Darwin X11. ---------------------------------------------------------------------- Comment By: Revar (revar) Date: 2005-03-15 15:36 Message: Logged In: YES user_id=6331 The following script, under OS X, will consistently crash stock Tk that hasn't yet been patched for this bug. Just click on the down arrow on the scrollbar to trigger. set textheight 12 set textwidth 30 frame .f -relief sunken -borderwidth 2 pack .f -padx 10 -pady 10 text .f.t -font {Courier 9} -height $textheight -width $textwidth -yscrollcommand ".f.sb set" scrollbar .f.sb -command ".f.t yview" pack .f.t -side left -expand 1 -fill both pack .f.sb -side right -fill y .f.t tag configure Header -font {Helvetica 14 bold italic} -wrap word -spacing1 12 -spacing3 4 .f.t insert end "Foo" Header for {set i 1} {$i < $textheight} {incr i} { .f.t insert end "\nLine $i" } ---------------------------------------------------------------------- Comment By: Vince Darley (vincentdarley) Date: 2005-03-15 06:08 Message: Logged In: YES user_id=32170 I took a close look at the patch and code, and added some more comments to tkTextDisp.c and committed a very similar patch to that provided here. Leaving open for a test case... ---------------------------------------------------------------------- Comment By: Vince Darley (vincentdarley) Date: 2005-03-15 02:35 Message: Logged In: YES user_id=32170 The given patch doesn't make any tests fail on WinTk, but it would be best if we can add a new test which would actually fail (crash) on as many platforms as possible without this patch. revar: could you try to provide a smallish test which crashes on TkAqua for you? ---------------------------------------------------------------------- Comment By: Revar (revar) Date: 2005-03-14 12:44 Message: Logged In: YES user_id=6331 Oh, and to answer the question, I'm running a modified Tk, based on the CVS HEAD branch. (All my mods are in the macosx branch, to let me have something approximating proper Aqua theme pinstripe backgrounds, focus halos, etc. They are completely unrelated to this bug.) I can reproduce the bug consistently due to a lucky coincidence of how my help window is filled out in one screen. The fix I posted below makes it stop panicking. ---------------------------------------------------------------------- Comment By: Revar (revar) Date: 2005-03-14 12:25 Message: Logged In: YES user_id=6331 I believe part of the trick of reproducing this is to have some fonts in the text widget that are not an even size divisor of the text widget height. ie: The last line is partial, etc. ---------------------------------------------------------------------- Comment By: Revar (revar) Date: 2005-03-14 12:18 Message: Logged In: YES user_id=6331 This is not OS X specific. I tracked down the bug to a few short lines in generic/tkTextDisp.c where it was incorrectly handling the vertical offset when it was at the start of the text buffer. I think I fixed this correctly. I tested it and it seems to work fine now, with a bonus of fixing a related noncrasher bug, where the scrollbar wouldn't show as scrollable, when the text display had just enough text in it to have the last line be displayed only partially. Here's the patch: --- tk/generic/tkTextDisp.c Fri Mar 11 15:36:26 2005 +++ head/tk/generic/tkTextDisp.c Fri Mar 11 13:03:17 2005 @@ -1922,10 +1922,11 @@ * need to store any extra overlap we've just * created for the top line. */ - if (lineNum >= 0) { + if (spaceLeft >= 0) { + dInfoPtr->newTopPixelOffset = 0; + } else { dInfoPtr->newTopPixelOffset = -spaceLeft; - if (spaceLeft > 0 || - dInfoPtr->newTopPixelOffset >= dInfoPtr->dLinePtr->height) { + if (dInfoPtr->newTopPixelOffset >= dInfoPtr->dLinePtr->height) { /* Bad situation */ Tcl_Panic("Pixel height problem while laying out text widget"); } ---------------------------------------------------------------------- Comment By: Vince Darley (vincentdarley) Date: 2005-03-14 10:24 Message: Logged In: YES user_id=32170 Hmm, in that case I have no idea what the problem is. Perhaps 'revar' can tell us what version of TkAqua is being used to reproduce the problem? ---------------------------------------------------------------------- Comment By: Jim Ingham (wolfsuit) Date: 2005-03-14 10:18 Message: Logged In: YES user_id=169107 I don't think this is relevant to this bug. I don't see it on the current TOT on 10.3 with the example cited. Note, the code is not calling "update" just "update idletasks". You can't call Tcl_ServiceAll because the Aqua code is using the Native Control to move the mouse around, and if you steal mouse events off the queue out from under the control, it doesn't move properly. But you can replace the call to "update idletasks" with a call to TclServiceIdle(). That seems to work just fine in my quick tests. The only difference between "update idletasks" and calling TclServiceIdle directly is that "update idletasks" calls XSync. This is redundant, because fetching the next event also flushes the drawing, and syncing with the server is a cross-process call on Mac OS X so it is more expensive than it was in the Classic MacOS. I think I will switch TOT to calling TclServiceIdle, since it seems to make the scrolling a little faster. But I don't think it has any relevance to this bug. ---------------------------------------------------------------------- Comment By: Jim Ingham (wolfsuit) Date: 2005-03-14 10:15 Message: Logged In: YES user_id=169107 I don't think this is relevant to this bug. I don't see it on the current TOT on 10.3 with the example cited. Note, the code is not calling "update" just "update idletasks". You can't call Tcl_ServiceAll because the Aqua code is using the Native Control to move the mouse around, and if you steal mouse events off the queue out from under the control, it doesn't move properly. But you can replace the call to "update idletasks" with a call to TclServiceIdle(). That seems to work just fine in my quick tests. The only difference between "update idletasks" and calling TclServiceIdle directly is that "update idletasks" calls XSync. This is redundant, because fetching the next event also flushes the drawing, and syncing with the server is a cross-process call on Mac OS X so it is more expensive than it was in the Classic MacOS. I think I will switch TOT to calling TclServiceIdle, since it seems to make the scrolling a little faster. But I don't think it has any relevance to this bug. ---------------------------------------------------------------------- Comment By: Jeffrey Hobbs (hobbs) Date: 2005-03-14 09:54 Message: Logged In: YES user_id=72656 Jim - want to comment on TkAqua's scrolling behavior? Seems dangerous to have an update occuring there. ---------------------------------------------------------------------- Comment By: Vince Darley (vincentdarley) Date: 2005-03-12 15:38 Message: Logged In: YES user_id=32170 The only thing I can possibly think of is that TkAqua's scrollbar implementation is basically a poor design (which differs in fundamental ways from the unix/windows code). The code issues 'update idletasks' events during scrolling. I thought there was an outstanding RFE or bug report on this issue, but I can't see it now. Anyway, not sure if it's relevant, but it might be. The best solution would really be to fix TkAqua's scrollbar, since its behaviour cause observable differences in Tcl script outcomes. ---------------------------------------------------------------------- Comment By: Jeffrey Hobbs (hobbs) Date: 2005-03-11 10:51 Message: Logged In: YES user_id=72656 I'm passing back to Vince to consider whether some aspect of the new code may be particularly OS X sensitive. He may want to pass on to DAS to see if a known OS X problem may be coinciding. ---------------------------------------------------------------------- Comment By: Revar (revar) Date: 2005-03-11 03:38 Message: Logged In: YES user_id=6331 I can consistently reproduce this under OS X Aqua. ---------------------------------------------------------------------- Comment By: Jeffrey Hobbs (hobbs) Date: 2005-02-18 12:12 Message: Logged In: YES user_id=72656 From NEM: I think something weird's going on with my machine. I can repro the bug consistently from the same machine/X server, but nowhere else. Even running the script remotely (x forwarding) doesn't reproduce the bug. So I guess it can be closed. ---------------------------------------------------------------------- Comment By: Jeffrey Hobbs (hobbs) Date: 2005-02-18 11:17 Message: Logged In: YES user_id=72656 I cannot repro on either Windows or Linux with the latest head (18 Feb 2005). Linux built was using xft. ---------------------------------------------------------------------- Comment By: Vince Darley (vincentdarley) Date: 2005-02-18 07:21 Message: Logged In: YES user_id=32170 Note: I can't reproduce this on Windows, so it's going to be hard to debug (for me) unless you can find another example which reproduces it on Windows too... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=112997&aid=1143776&group_id=12997 |