Bugs item #979640, was opened at 2004-06-25 11:30
Message generated for change (Settings changed) made by dkf
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=979640&group_id=10894
Category: 08. Environment Variables
Group: current: 8.5a1
Status: Open
Resolution: None
>Priority: 7
Submitted By: Steve Bold (stevebold)
Assigned to: Jeffrey Hobbs (hobbs)
Summary: Buffer overruns mixing C and Tcl environment changes
Initial Comment:
I have an application which embeds Tcl but which has
other components not using Tcl. The app runs Tcl
scripts which modify the environment but the non-Tcl
components also modify the environment using direct
calls to the C function putenv().
The original problem I encountered was that the
application sometimes crashed on startup when run on
Linux using Tcl 8.4.3 and the crash occurred when in
a call to TclSetEnv(). Debugging the startup sequence
using Purify on Solaris showed Array Buffer Write
(ABW) errors when Tcl modifies the environment,
though on Solaris this did not cause a crash. I have
since reproduced the problem using 8.5a1 and reduced
the application to a small test case involving one
Tcl script and one C file, which are given below:
/* CrashEnv.c - compile as a shared library CrashEnv.so
*/
#include <tcl.h>
#include <stdlib.h>
static int myCmd(ClientData dummy,Tcl_Interp*
interp,int objc,Tcl_Obj* CONST* objv)
{
putenv("a=b");
}
int Envcrash_Init(Tcl_Interp* interp)
{
if (Tcl_InitStubs(interp,"8.4",0) == NULL) {
return TCL_ERROR;
}
Tcl_CreateObjCommand(interp,"myCmd",myCmd,0,0);
return TCL_OK;
}
/* End CrashEnv.c */
# CrashEnv.tcl - source in a tclsh built using Purify and
see an ABW error.
set env(m) 1
load [pwd]/EnvCrash.so
myCmd
set env(l) 2; # ABW here.
# end CrashEnv.tcl
I believe the root of problem is this:
When TclSetEnv() is first asked to add a variable to
the environment, it determines that the length of the
current environment is 10. It needs to allocate a new
environ array sized to at least 12, allowing space
for the new entry and null terminator.
It actually allocates 15 elements. This gives it
space for an extra 3 variables, reducing the
frequence of reallocations.
Subsequently the application makes a direct call to
putenv() and it finds it needs to add a variable to
the environment. It sees that there are 11 variables
in the environment. With a new variable and
terminator the required length is 13, so it allocates
this size as the new environ array.
The script then modifies the environment again,
triggering another call to TclSetEnv(). It sees there
are 12 variables in the environment. With the new
variable and null terminator, a length of 14 is
needed. It remembers that it has previously allocated
space for 15 and so does not extend the array.
Unfortunately, this isn't safe.
It is possible that some implementations of putenv()
employ similar optimisations, so the same problem
might possibly occur the other way around. I conclude
that you cannot allow multiple components to modify
environ.
I can work around the problem by setting $(ENV_FLAGS)
to -DUSE_PUTENV in the Makefile. Possibly this is a
valid fix for the problem?
Purify output from above test using 8.5a1
**** Purify
instrumented /eeg/home/stevebo/tcl8.5a1/unix/tclsh
(pid 1476) ****
ABW: Array bounds write:
* This is occurring while in:
TclSetEnv [tclEnv.c:214]
EnvTraceProc [tclEnv.c:561]
TclCallVarTraces [tclTrace.c:2516]
TclPtrSetVar [tclVar.c:1679]
Tcl_ObjSetVar2 [tclVar.c:1515]
Tcl_SetObjCmd [tclVar.c:1286]
TclEvalObjvInternal [tclBasic.c:3147]
Tcl_EvalEx [tclBasic.c:3642]
Tcl_FSEvalFileEx [tclIOUtil.c:1665]
Tcl_Main [tclMain.c:380]
main [tclAppInit.c:90]
_start [crt1.o]
* Writing 4 bytes to 0xaa604 in the heap.
* Address 0xaa604 is 1 byte past end of a malloc'd
block at 0xaa4d8 of 300 bytes.
* This block was allocated from:
malloc [rtlib.o]
putenv [libc.so.1]
myCmd [EnvCrash.c]
TclEvalObjvInternal [tclBasic.c:3147]
Tcl_EvalEx [tclBasic.c:3642]
Tcl_FSEvalFileEx [tclIOUtil.c:1665]
Tcl_Main [tclMain.c:380]
main [tclAppInit.c:90]
_start [crt1.o]
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=979640&group_id=10894

Bugs item #979640, was opened at 2004-06-25 10:30
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=979640&group_id=10894
Category: 08. Environment Variables
Group: current: 8.5a1
Status: Open
Resolution: None
Priority: 5
Submitted By: Steve Bold (stevebold)
Assigned to: Jeffrey Hobbs (hobbs)
Summary: Buffer overruns mixing C and Tcl environment changes
Initial Comment:
I have an application which embeds Tcl but which has
other components not using Tcl. The app runs Tcl
scripts which modify the environment but the non-Tcl
components also modify the environment using direct
calls to the C function putenv().
The original problem I encountered was that the
application sometimes crashed on startup when run on
Linux using Tcl 8.4.3 and the crash occurred when in
a call to TclSetEnv(). Debugging the startup sequence
using Purify on Solaris showed Array Buffer Write
(ABW) errors when Tcl modifies the environment,
though on Solaris this did not cause a crash. I have
since reproduced the problem using 8.5a1 and reduced
the application to a small test case involving one
Tcl script and one C file, which are given below:
/* CrashEnv.c - compile as a shared library CrashEnv.so
*/
#include <tcl.h>
#include <stdlib.h>
static int myCmd(ClientData dummy,Tcl_Interp*
interp,int objc,Tcl_Obj* CONST* objv)
{
putenv("a=b");
}
int Envcrash_Init(Tcl_Interp* interp)
{
if (Tcl_InitStubs(interp,"8.4",0) == NULL) {
return TCL_ERROR;
}
Tcl_CreateObjCommand(interp,"myCmd",myCmd,0,0);
return TCL_OK;
}
/* End CrashEnv.c */
# CrashEnv.tcl - source in a tclsh built using Purify and
see an ABW error.
set env(m) 1
load [pwd]/EnvCrash.so
myCmd
set env(l) 2; # ABW here.
# end CrashEnv.tcl
I believe the root of problem is this:
When TclSetEnv() is first asked to add a variable to
the environment, it determines that the length of the
current environment is 10. It needs to allocate a new
environ array sized to at least 12, allowing space
for the new entry and null terminator.
It actually allocates 15 elements. This gives it
space for an extra 3 variables, reducing the
frequence of reallocations.
Subsequently the application makes a direct call to
putenv() and it finds it needs to add a variable to
the environment. It sees that there are 11 variables
in the environment. With a new variable and
terminator the required length is 13, so it allocates
this size as the new environ array.
The script then modifies the environment again,
triggering another call to TclSetEnv(). It sees there
are 12 variables in the environment. With the new
variable and null terminator, a length of 14 is
needed. It remembers that it has previously allocated
space for 15 and so does not extend the array.
Unfortunately, this isn't safe.
It is possible that some implementations of putenv()
employ similar optimisations, so the same problem
might possibly occur the other way around. I conclude
that you cannot allow multiple components to modify
environ.
I can work around the problem by setting $(ENV_FLAGS)
to -DUSE_PUTENV in the Makefile. Possibly this is a
valid fix for the problem?
Purify output from above test using 8.5a1
**** Purify
instrumented /eeg/home/stevebo/tcl8.5a1/unix/tclsh
(pid 1476) ****
ABW: Array bounds write:
* This is occurring while in:
TclSetEnv [tclEnv.c:214]
EnvTraceProc [tclEnv.c:561]
TclCallVarTraces [tclTrace.c:2516]
TclPtrSetVar [tclVar.c:1679]
Tcl_ObjSetVar2 [tclVar.c:1515]
Tcl_SetObjCmd [tclVar.c:1286]
TclEvalObjvInternal [tclBasic.c:3147]
Tcl_EvalEx [tclBasic.c:3642]
Tcl_FSEvalFileEx [tclIOUtil.c:1665]
Tcl_Main [tclMain.c:380]
main [tclAppInit.c:90]
_start [crt1.o]
* Writing 4 bytes to 0xaa604 in the heap.
* Address 0xaa604 is 1 byte past end of a malloc'd
block at 0xaa4d8 of 300 bytes.
* This block was allocated from:
malloc [rtlib.o]
putenv [libc.so.1]
myCmd [EnvCrash.c]
TclEvalObjvInternal [tclBasic.c:3147]
Tcl_EvalEx [tclBasic.c:3642]
Tcl_FSEvalFileEx [tclIOUtil.c:1665]
Tcl_Main [tclMain.c:380]
main [tclAppInit.c:90]
_start [crt1.o]
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=979640&group_id=10894

Bugs item #979239, was opened at 2004-06-24 21:28
Message generated for change (Comment added) made by dkf
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=112997&aid=979239&group_id=12997
Category: 41. Photo Images
>Group: development: 8.5a2
Status: Open
>Resolution: Fixed
>Priority: 9
Submitted By: Erik Leunissen (eriklns)
>Assigned to: Donal K. Fellows (dkf)
Summary: program crash with PNG images
Initial Comment:
Note first off:
This bug report is cross posted to both the Img
extension and the Tk toolkit. The reason for this is
that I cannot determine whether the bug concerns only
Tk, only Img, or both. A thread in c.l.t around
23-Jul-2004 did not come up with a conclusion regarding
the cause.
Sincerely,
Erik Leunissen
==============
# The following script exercises problems with PNG images,
# resulting in a program crash, leaving behind an error
message
# of the following format (XXX is a number that varies):
#
# X Error of failed request: BadMatch (invalid
parameter attributes)
# Major opcode of failed request: 73 (X_GetImage)
# Serial number of failed request: XXX
# Current serial number in output stream: XXX
#
# - I used:
# - Linux (the problems did not occur under Windows)
# - Tcl/Tk 8.4.6
# - Img1.3
#
# - This script uses a label widget, but the crashes occur
# also when using buttons instead of labels.
#
# - You may need to set the width and height to some
initial
# value, big enough to display the entire image
#
# - Choose one of the two crash attempts below
#
package require Img
image create photo png -file ./Error.png
pack [label .l -width 0 -height 0]
# PNG CRASH #1
# First insert the image, then fix size (-width or -height,
# I show -width only) to a non-zero value too small to
display
# the entire image.
.l configure -image png
.l configure -width 2 ; # <-- crash occurs here
# PNG CRASH #2
# First fix size (width or height) to a non-zero value too
# small to display the entire image; then insert the image.
.l configure -width 2
.l configure -image png ; # <-- crash occurs here
# EOF
----------------------------------------------------------------------
>Comment By: Donal K. Fellows (dkf)
Date: 2004-06-25 09:46
Message:
Logged In: YES
user_id=79902
It's a Tk fault.
Tk 8.4 (at some patch level) introduced proper display of
images with non-trivial alpha channels, and as part of
implementing this, an XGetImage() call is required (to get
the background data that the image is going to be blended
with, of course.) However, the XGetImage() function does
not like being called with a zero width or height
(apparently; the X docs are not very clear about the exact
situations under which you really get errors, but I bet this
is one of them) unlike the mechanism used when a trivial
alpha channel is all we've got. I'm not 100% sure of why
the crash doesn't happen when both -width and -height are 0,
but I suspect in that case we're not getting an Expose event...
All Img does in this scenario is create images with
non-trivial alpha channels (which is one of the key features
of the PNG format.)
I believe the fix is simply to check for zero widths and
heights in ImgPhotoDisplay in tkImgPhoto.c and return early
from the function in that case. I attach the patch I used
for 8.4
Currently, there's no mechanism for testing this (that
requires an API I've proposed in a TIP) so the bug should
not be closed.
----------------------------------------------------------------------
Comment By: Joe Mistachkin (mistachkin)
Date: 2004-06-25 04:54
Message:
Logged In: YES
user_id=113501
I can confirm intermittent crashes with PNGs using Img 1.3
(in "pngtcl10.dll").
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=112997&aid=979239&group_id=12997