panic in Range_ItemUnderPoint

Logged In: YES
user_id=108900
Originator: YES

I can add that he build was made with a version where the head of tkTreeDisplay.c is
* RCS: @(#) $Id: tkTreeDisplay.c,v 1.85 2008/01/22 01:03:02 treectrl Exp $
which I believe is current cvs to date. On Windows I built it with MinGW.

Logged In: YES
user_id=108900
Originator: YES

Just got it on MacOSX.
* RCS: @(#) $Id: tkTreeDisplay.c,v 1.85 2008/01/22 01:03:02 treectrl Exp $

Process: Wish [163]
Path: /Library/Frameworks/Tk.framework/Versions/8.5/Resources/Wish.app/Contents/MacOS/Wish
Identifier: com.tcltk.wish
Version: 8.5.2 (8.5.2)
Code Type: X86 (Native)
Parent Process: launchd [64]

Date/Time: 2008-04-18 15:05:13.723 +0200
OS Version: Mac OS X 10.5.2 (9C31)
Report Version: 6

Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Crashed Thread: 0

Thread 0 Crashed:
0 libSystem.B.dylib 0x915340ea __kill + 10
1 libSystem.B.dylib 0x915ab3f2 raise + 26
2 libSystem.B.dylib 0x915ba9af abort + 73
3 com.tcltk.tcllibrary 0x0a07d602 Tcl_Panic + 0
4 com.tcltk.tcllibrary 0x0a07d61d Tcl_Panic + 27
5 libtreectrl2.2.dylib 0x0eff391b Range_ItemUnderPoint + 392
6 libtreectrl2.2.dylib 0x0eff79a2 Tree_UpdateDInfo + 701
7 libtreectrl2.2.dylib 0x0effb1ff Tree_Display + 1383
8 com.tcltk.tcllibrary 0x0a0956fe TclServiceIdle + 61
9 com.tcltk.tcllibrary 0x0a07aa4f Tcl_DoOneEvent + 379
10 com.tcltk.tklibrary 0x0b013d88 Tk_MainLoop + 37
11 com.tcltk.tklibrary 0x0b021067 Tk_MainEx + 1923
12 com.tcltk.wish 0x000045d3 0x1000 + 13779
13 com.tcltk.wish 0x0000458e 0x1000 + 13710
14 com.tcltk.wish 0x000044b5 0x1000 + 13493

Logged In: YES
user_id=669413
Originator: NO

I keep looking into this bug.
In those bug reports y is always negative.
Assuming this is line tkTreeDisplay.c:3247 then either minY
or tree->yOrigin is being calculated incorrectly.
Did you get this bug right after opening/closing items?

Logged In: YES
user_id=108900
Originator: YES

First, this bug is very rare. In fact, personally I have seen it only once despite I excersize this code very much.
Second, it happens during login to a jabber account, and the users list (treectrl) is then filled in from xml,
and a lot happens at the same time. However, I might have noticed that I had the pointer over the treectrl widget,
nd I have some generic code:
http://coccinella.cvs.sourceforge.net/coccinella/coccinella/contrib/treeutil.tcl?view=markup
to be able to bind events directly to items. It could be something here that triggers it.

Logged In: NO

It keeps happening each time I try to scroll vertically with the mouse wheel inside the TreeCtrl on Vista, this didn't use to happened with me on XP, I've made some debugging and found that this is due to tree->yOrigin to have garbage values, I'm using Tcl/Tk 8.5.3

Logged In: NO

#1702066 is a duplicate of this bug. It happens on various machines when i use the scroll wheel.
An upgrade from 2.2.3 to 2.2.7 doesn't improve the case. Easy to reproduce here.

I checked tktreectrl-2.2.7 with valgrind. Maybe this reports can help to find
the problem:

==23771== Conditional jump or move depends on uninitialised value(s)
==23771== at 0x5F13D62: Column_DoLayout (tkTreeColumn.c:2857)
==23771== by 0x8: ???

This is the line:
padList[n] = MAX(partImage.padX[PAD_TOP_LEFT], padList[n]);

It seems to me, that padList[n] isn't initialized.

==23771== Invalid read of size 4
==23771== at 0x5F23F66: Increment_AddY (tkTreeDisplay.c:1043)
==23771== Address 0x4f566f4 is 4 bytes before a block of size 40 alloc'd
==23771== at 0x401CC1E: malloc (vg_replace_malloc.c:207)
==23771== by 0x414A2BA: TclpAlloc (tclAlloc.c:706)

The concering code:

while ((visHeight > 1) &&
(offset - dInfo->yScrollIncrements[dInfo->yScrollIncrementCount - 1]
> visHeight)) {

I replaced the second part by

while ((visHeight > 1) && dInfo->yScrollIncrementCount > 0 &&
(offset - dInfo->yScrollIncrements[dInfo->yScrollIncrementCount - 1]
> visHeight)) {

- and the problem is gone! Juchhu!

Wow! Nice job. Amazing it ever worked.

I just saw the cvs comment: the patch was from me (Christoph Bauer) ;-)
Sorry for posting it as nobody and thanks for applying it!