[Tcl-bugs] tcl-cvs: "tcl/generic tclCmdMZ.c tclExecute.c tclGet.c tclObj.c tclParseExpr.c" modified

[Kevin B KENNY <kennykb@us...>]

Update of /cvsroot/tcl/tcl/generic
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv9432/generic

Modified Files:
      Tag: kennykb-numerics-branch
	tclCmdMZ.c tclExecute.c tclGet.c tclObj.c tclParseExpr.c 
Log Message:
made code permissive about infinities

[Tcl-bugs] tcl-cvs: "tcl ChangeLog" modified

[Kevin B KENNY <kennykb@us...>]

Update of /cvsroot/tcl/tcl
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv9432

Modified Files:
      Tag: kennykb-numerics-branch
	ChangeLog 
Log Message:
made code permissive about infinities

[Tcl-bugs] [ tcl-Bugs-1078024 ] threaded exit can reinit PipeInit on exit and crash

[SourceForge.net <noreply@so...>]

Bugs item #1078024, was opened at 2004-12-02 16:08
Message generated for change (Comment added) made by mistachkin
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=1078024&group_id=10894

Category: 47. Threading
Group: obsolete: 8.4.8
Status: Open
Resolution: None
Priority: 7
Submitted By: Jeffrey Hobbs (hobbs)
Assigned to: David Gravereaux (davygrvy)
Summary: threaded exit can reinit PipeInit on exit and crash

Initial Comment:
There is an issue with finalization of the threaded
Windows build that can appear in winDde.test and
occasionally winPipe.test.  Kevin narrowed it down to
this series of events:

* Tcl_Finalize is called from Tcl_Exit and runs all the
exit handlers.

* After all the exit handlers are run, it winds up
calling Tcl_FinalizeThread.

* From there we get into Tcl_FinalizeIOSubsystem, and
thence to Tcl_Close

* We have an open pipe at this point, so we get into
PipeClose2Proc from tclWinPipe.c.

* This calls Tcl_CleanupChildren -> Tcl_WaitPid

* and Tcl_WaitPid finds that the pipe subsystem isn't
initialized - because its exit handler has already run,
so calls PipeInit, re-establishing the exit handler.

* Now we shut down the zippy memory allocator - with
the exit handler still on the list.

* The last-ditch Tcl_Finalize in DLL_PROCESS_DETACH
finds the exit handler and runs it - and then frees the
memory.

* Which is now in use as a CRITICAL_SECTION down in the
C runtime... boom.

* I believe that it's a threaded problem only, and the
exit handler is being created in Windows-specific code.

* I don't know if there's similar code in Unix.

This is perhaps related to 990457 (this is unix
specific, but about threaded exit behavior)


----------------------------------------------------------------------

>Comment By: Joe Mistachkin (mistachkin)
Date: 2005-03-03 23:29

Message:
Logged In: YES 
user_id=113501

Argle.  I bet this is causing a number of issues I've been
seeing on Win32.  

Unfortunately, I do not know enough about how the IO
subsystem is supposed to work.

This bug is only loosely related to bug 990457, if at all.
This bug is almost certainly related to bug 912571.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=1078024&group_id=10894

[Tcl-bugs] [ tktoolkit-Bugs-1155596 ] TkAqua: crash when using buttons with image with alpha

[SourceForge.net <noreply@so...>]

Bugs item #1155596, was opened at 2005-03-02 21:33
Message generated for change (Comment added) made by muonics
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112997&aid=1155596&group_id=12997

Category: 66. Aqua Window Operations
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Kirkham (muonics)
Assigned to: Daniel A. Steffen (das)
Summary: TkAqua: crash when using buttons with image with alpha

Initial Comment:
set img [image create photo -file image-with-alpha.png]
pack [button .b -image $img]

The button is not displayed, and "OpenCPicture failed"
is printed to stderr.  Subsequently interacting with
the GUI results in a crash.  This happens both with
TkImg and with the PNG parser I'm implementing.  It
does not crash with labels.

0   com.apple.QD            0x9156d270 SetGWorld +
0x401   com.tcltk.tklibrary     0x0b079e68 TkPutImage +
0x300
2   com.tcltk.tklibrary     0x0b040950 ImgPhotoDisplay
+ 0x1043   com.tcltk.tklibrary     0x0b039700
Tk_RedrawImage + 0xb8
4   com.tcltk.tklibrary     0x0b075924 SetupBevelButton
+ 0x1385   com.tcltk.tklibrary     0x0b075694
TkMacOSXDrawControl + 0x29c
6   com.tcltk.tklibrary     0x0b074638 TkpDisplayButton
+ 0x1287   com.tcltk.tcllibrary    0x0a0678f8
TclServiceIdle + 0x68
8   com.tcltk.tcllibrary    0x0a056dac Tcl_DoOneEvent +
0x1809   com.tcltk.tklibrary     0x0b02bcf4 Tk_MainLoop
+ 0x18
10  com.tcltk.tklibrary     0x0b04936c Tk_MainEx +
0x33811  com.tcltk.wish          0x000163c4 0x1000 +
0x153c4
12  com.tcltk.wish          0x00015e80 0x1000 +
0x14e8013  dyld                    0x8fe1a558
_dyld_start + 0x64

----------------------------------------------------------------------

>Comment By: Michael Kirkham (muonics)
Date: 2005-03-03 21:53

Message:
Logged In: YES 
user_id=498198

If I comment out the ImgPhotoBlendComplexAlpha() call, so
that in theory it should display just the background image
that the actual image gets blended with, a rather odd thing
results, shown in the attached image.

Commenting out the XGetPixel/XPutPixel in IPBCA results in
the same.  It requires both the be commented out.  Either
one uncommented results in the button not being displayed at
all, and crashing after interacting with the GUI.  It seems
to really Not Like that background image generated by
XGetImage().

----------------------------------------------------------------------

Comment By: Michael Kirkham (muonics)
Date: 2005-03-03 19:25

Message:
Logged In: YES 
user_id=498198

I've traced it down to the if
((instancePtr->masterPtr->flags & COMPLEX_ALPHA) ...) block
of ImgPhotoDisplay(), which generates an XImage from the
background and blends it with the image to be displayed.  If
the alternate path is used (the one used for images without
alpha) it displays the button normally with the image and
doesn't crash, but then of course no alpha blending is done
anywhere.

It seems rather wrong that it would be trying to blend with
a generated image from the background, however - the
background in this case is a button control that is in the
process of being drawn.

----------------------------------------------------------------------

Comment By: Michael Kirkham (muonics)
Date: 2005-03-02 21:51

Message:
Logged In: YES 
user_id=498198

Actually it doesn't print "OpenCPicture failed" until I
resize the window.  It seems the crash is because it goes
ahead and continues despite the failure; tossing a "return"
in after the error message is printed seems to prevent the
crash, although the message is still printed with any
resizing or interaction and the button isn't displayed.

I notice tkMacOSXMenubutton.c also makes a call to
OpenCPicture which similarly continues after fail rather
than returning.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112997&aid=1155596&group_id=12997

[Tcl-bugs] [ tktoolkit-Bugs-1155596 ] TkAqua: crash when using buttons with image with alpha

[SourceForge.net <noreply@so...>]

Bugs item #1155596, was opened at 2005-03-02 21:33
Message generated for change (Comment added) made by muonics
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112997&aid=1155596&group_id=12997

Category: 66. Aqua Window Operations
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Kirkham (muonics)
Assigned to: Daniel A. Steffen (das)
Summary: TkAqua: crash when using buttons with image with alpha

Initial Comment:
set img [image create photo -file image-with-alpha.png]
pack [button .b -image $img]

The button is not displayed, and "OpenCPicture failed"
is printed to stderr.  Subsequently interacting with
the GUI results in a crash.  This happens both with
TkImg and with the PNG parser I'm implementing.  It
does not crash with labels.

0   com.apple.QD            0x9156d270 SetGWorld +
0x401   com.tcltk.tklibrary     0x0b079e68 TkPutImage +
0x300
2   com.tcltk.tklibrary     0x0b040950 ImgPhotoDisplay
+ 0x1043   com.tcltk.tklibrary     0x0b039700
Tk_RedrawImage + 0xb8
4   com.tcltk.tklibrary     0x0b075924 SetupBevelButton
+ 0x1385   com.tcltk.tklibrary     0x0b075694
TkMacOSXDrawControl + 0x29c
6   com.tcltk.tklibrary     0x0b074638 TkpDisplayButton
+ 0x1287   com.tcltk.tcllibrary    0x0a0678f8
TclServiceIdle + 0x68
8   com.tcltk.tcllibrary    0x0a056dac Tcl_DoOneEvent +
0x1809   com.tcltk.tklibrary     0x0b02bcf4 Tk_MainLoop
+ 0x18
10  com.tcltk.tklibrary     0x0b04936c Tk_MainEx +
0x33811  com.tcltk.wish          0x000163c4 0x1000 +
0x153c4
12  com.tcltk.wish          0x00015e80 0x1000 +
0x14e8013  dyld                    0x8fe1a558
_dyld_start + 0x64

----------------------------------------------------------------------

>Comment By: Michael Kirkham (muonics)
Date: 2005-03-03 19:25

Message:
Logged In: YES 
user_id=498198

I've traced it down to the if
((instancePtr->masterPtr->flags & COMPLEX_ALPHA) ...) block
of ImgPhotoDisplay(), which generates an XImage from the
background and blends it with the image to be displayed.  If
the alternate path is used (the one used for images without
alpha) it displays the button normally with the image and
doesn't crash, but then of course no alpha blending is done
anywhere.

It seems rather wrong that it would be trying to blend with
a generated image from the background, however - the
background in this case is a button control that is in the
process of being drawn.

----------------------------------------------------------------------

Comment By: Michael Kirkham (muonics)
Date: 2005-03-02 21:51

Message:
Logged In: YES 
user_id=498198

Actually it doesn't print "OpenCPicture failed" until I
resize the window.  It seems the crash is because it goes
ahead and continues despite the failure; tossing a "return"
in after the error message is printed seems to prevent the
crash, although the message is still printed with any
resizing or interaction and the button isn't displayed.

I notice tkMacOSXMenubutton.c also makes a call to
OpenCPicture which similarly continues after fail rather
than returning.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112997&aid=1155596&group_id=12997

[Tcl-bugs] [ tktoolkit-Patches-1156388 ] Tip to add -initialtype

[SourceForge.net <noreply@so...>]

Patches item #1156388, was opened at 2005-03-03 18:03
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312997&aid=1156388&group_id=12997

Category: 37. [tk_get*File]
Group: TIP Implementation
Status: Open
Resolution: None
Priority: 5
Submitted By: Brian Griffin (bgriffin)
Assigned to: Jeffrey Hobbs (hobbs)
Summary: Tip to add -initialtype

Initial Comment:
Here's the *nix and Win implementation for the
-initialtype tip. I'm assuming the macosx impl. will be
just as trivial.

-Brian

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312997&aid=1156388&group_id=12997

[Tcl-bugs] tk-cvs: "tk/win tkWinX.c" modified

[Jeffrey Hobbs <hobbs@us...>]

Update of /cvsroot/tktoolkit/tk/win
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv18978/win

Modified Files:
	tkWinX.c 
Log Message:
correct xany -> xkey typo from 2005-02-28 commit