Logged In: YES
user_id=72656

assigning to Jim Ingham, but moved to pending because the
report doesn't have any details (repro script and such).
This is likely a better question for the tcl-mac mailing
list.

Logged In: NO

Hi
I will forward the script with details tomorrow.
rob
ramsayr@toronto.cbc.ca

Logged In: NO

Hi Jim

The actual file is approx 700k.

In order for it to run up there are a series of
exec statements that have it connect to a digital
disk device via a network connect. If this fails
you never make it to the gui part.

I have a system setup here and would be more than
happy to run any modified bits of code to better
understand what's happening.

If you still feel that you would like to look
at the tcl file, please let me know where you
would like me to leave it.

rob
ramsayr@toronto.cbc.ca
mochyn-mawr@rogers.com

Logged In: YES
user_id=169107

Well, what would be great is to get a backtrace for the
crash, and the Tcl code that is being run at the time of
the crash. To get a backtrace, just run the Wish shell
under gdb, and when it crashes, you can type:

thread apply all bt

Send me that output.

You can find out what Tcl code is being run by looking
up the stack for occurances of TclExecuteByteCode,
and look at codePtr->source in that frame. The Tcl
stack mirrors the C stack, so you can reconstruct the
whole Tcl stack pretty easily this way.

You should be able to chase that fragment back to the
source proc, and send me that routine. Also if you can
tell me how it is being run, is it straight code, button
callback, menu callback, event binding, etc, that would
help...

If it is anything but straight code, you could also send
along the snippet where it is set up, the bind
command, or whatever.

I can often figure out what is going on from this info, or
at least figure out where to put instrumentation to
chase it down further.

Thanks.

Logged In: NO

Hi Jim
here's the output from gdb
I will dig a little deeper tomorrow.(chase fragment)
rob
ramsayr@toronto.cbc.ca
mochyn-mawr@rogers.com

(gdb) run
Starting program: /Applications/Wish
Shell.app/Contents/MacOS/./Wish
Shell /ProntoVideo/Src/pronto_gui.tcl
[Switching to thread 1 (process 4822 thread 0x1603)]
Reading symbols for shared
libraries ............................................. done

Program received signal EXC_BAD_ACCESS, Could not access
memory.
0x7000591c in strncpy ()
(gdb) thread apply all bt

Thread 2 (process 4822 thread 0x1f17):
#0 0x70025cac in select ()
#1 0x005e21b0 in NotifierThreadProc (clientData=0x7) at
tkMacOSXNotify.c:1027
#2 0x70020efc in _pthread_body ()

Thread 1 (process 4822 thread 0x1603):
#0 0x7000591c in strncpy ()
#1 0x0058d784 in Tk_GetFirstTextLayout (layout=0x295d810,
font=0xbfffc9c8, dst=0xbfffca49 "")
at ../generic/tkFont.c:3708
#2 0x005e01d0 in ComputeControlTitleParams
(butPtr=0xbfffca49, paramsPtr=0xbfffca44) at
tkMacOSXMenubutton.c:555
#3 0x005dfa7c in TkpDisplayMenuButton
(clientData=0xbfffca49) at tkMacOSXMenubutton.c:231
(gdb)

Logged In: YES
user_id=169107

This is caused by doing:

button .b -text ""
pack .b

The problem was that we were grabbing the first text
layout of the button string (the Aqua button CDEF really
didn't like buttons with newlines in the text). But we
didn't handle the case where the text was a null string.

The patch is:

Index: tkFont.c

========================
RCS file: /cvsroot/tktoolkit/tk/generic/tkFont.c,v
retrieving revision 1.12.2.1
diff -p -r1.12.2.1 tkFont.c
*** tkFont.c 2001/10/15 09:22:00 1.12.2.1
--- tkFont.c 2002/01/22 01:09:04
*************** Tk_GetFirstTextLayout(
*** 3697,3706 ****
int numDisplayChars;

layoutPtr = (TextLayout *)layout;
! if (layoutPtr==NULL) {
! return 0;
! }
! if (layoutPtr->numChunks==0) {
return 0;
}
chunkPtr = layoutPtr->chunks;
--- 3697,3706 ----
int numDisplayChars;

layoutPtr = (TextLayout *)layout;
! if ((layoutPtr==NULL)
! || (layoutPtr->numChunks==0)
! || (layoutPtr->chunks->numDisplayChars <= 0))
{
! dst[0] = '\0';
return 0;
}
chunkPtr = layoutPtr->chunks;

I checked this in.