Bugs item #768678, was opened at 2003-07-09 12:19
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=768678&group_id=10894
Category: 25. Channel System
Group: 8.4.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Andreas Kupries (andreas_kupries)
Summary: open "|prog >file" throws error but still executes prog
Initial Comment:
e.g.: set pipe [open "|echo foo >bar" r]
rightly throws an error, because stdout is redirected in
a pipe opened for reading.
But: by the time it complains, the pipeline has already
been executed (with all it's sideeffects) or is still running
in the background and no channel is assigned, so these
processes of the pipe cannot be identified.
A solution to this would likely involve changing the
signature of TclCreatePipeline() (although it is
"unofficially exported for BLT").
One solution could be to add an integer "flags"
argument, similar to Tcl_OpenCommandChannel()
and pass along TCL_STDIN and/or TCL_STDOUT
depending on whether the pipe is opened for r,w or
both, doing the forbid-mechanics one level deeper
than where it is done now.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=768678&group_id=10894

Bugs item #768664, was opened at 2003-07-09 11:58
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=768664&group_id=10894
Category: 25. Channel System
Group: 8.4.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Andreas Kupries (andreas_kupries)
Summary: TclCreatePipeline still alters argv
Initial Comment:
Symptom:
A previous bugfix only restored one case
of a modifed argv-entry, but didn't affect
two other modifications of argv:
- pipes ("|" and "|&") are replaced by NULL
- redirections are removed.
This may or may not be a real problem.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=768664&group_id=10894

Bugs item #768659, was opened at 2003-07-09 11:53
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=768659&group_id=10894
Category: 25. Channel System
Group: 8.4.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Andreas Kupries (andreas_kupries)
Summary: pipeline with empty last command not always recognized
Initial Comment:
Symptom:
[exec echo foo | >foobar ]
should throw an exception just like
[exec echo foo | ]
Bug-description:
for each "|" or "|&" the code checks, whether that was
the last argument, and if so: throws an error.
Thereby it misses those cases where only redirections
follow the last pipe.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=768659&group_id=10894

Bugs item #767176, was opened at 2003-07-07 09:12
Message generated for change (Comment added) made by muonics
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=112997&aid=767176&group_id=12997
Category: 68. Win Window Operations
Group: 8.4.3
Status: Open
Resolution: None
Priority: 8
Submitted By: Michael Kirkham (muonics)
Assigned to: Chengye Mao (chengyemao)
Summary: Bad winPtr->window pointer causes crash in Tk_GetHWND
Initial Comment:
This is a somewhat obscure and intermitted crash,
demonstrated by the attached script which requires
Bryan Oakley's combobox implementation (demonstrated
with version 2.2.1). An access violation occurs when
WmProc() in tkWinWm.c gets called with a WM_ACTIVATEAPP
event. This isn't in the switch so it goes on to get
winPtr:
winPtr = GetTopLevel(hwnd);
Unfortunately, the value sometimes comes up bogus
(filled with bad pointers and such) and when it
subsequently calls Tk_GetHWND(winPtr), it crashes from
winPtr->window being a bad pointer when attempting to
get winPtr->window.handle.
After lots of experimentation, I was able to cause the
crash with a straight wish running the script (as
opposed to the extended wish plus other Tcl code for my
application, which originally seemed partly involved
due to the intermittent nature of the crash) .
For convenience I've made the buttons take up the huge
area of the main toplevel (.), but that doesn't matter
for demonstrating the crash -- it just keeps you from
having to move the mouse around a bunch. The crash
does, however, seem to involve some of the geometry
operations going on to center and size the various
windows, combined with the combobox and the window
icon. Commenting out any one of these *seems* to stop
the crash from happening, but since it's intermittent
it is hard to be sure. In case it matters, I'm also
attaching the icon I'm using.
To demonstrate, after launching the script, click the
button that says "Combo". A new toplevel will be
created, centered on the screen, with a combobox in it.
Close the window (click the [X] icon). It seems to
occur more often if you repeat this (click the "Combo"
button, close the window that pops up) a couple times.
Then click exit. Often, but not always, this will
crash (with an invalid page fault or an access
violation depending on whether or not
you're running wish from within DevStudio). After
rebuilding wish with debugging symbols and running from
DevStudio I was able to track the crash to the WmProc()
and Tk_GetHWND().
----------------------------------------------------------------------
>Comment By: Michael Kirkham (muonics)
Date: 2003-07-09 05:54
Message:
Logged In: YES
user_id=498198
More curious: altering the order of operations so that the
combobox is added to the toplevel first, then it's centered,
*then* the title and iconbitmap are set, results in the
"cmbtopxxx" transient toplevel things not even being listed
by Spy++ -and- it doesn't seem to crash that way. This
leads me more strongly to think there might be some sort of
race condition, perhaps in some combination of the these
three things happening prior to the window being posted.
----------------------------------------------------------------------
Comment By: Michael Kirkham (muonics)
Date: 2003-07-09 05:28
Message:
Logged In: YES
user_id=498198
Poking around with the VC++ debugger and Spy++, I've been
able to figure out that the HWND receiving the
WM_ACTIVATEAPP event is that of the transient toplevel for
the combobox (that's displayed when you hit the little down
arrow button to show the list). Sort of. Curiously, Spy++
shows show TkToplevel's with the name I changed that
transient to (instead of .top, for debugging). One with
children, one without. It would seem that the problem is
either some race condition, something is being left
incomplete about the destruction of this transient toplevel
when the toplevel containing the combobox is destroyed, or
for some reason Tk creates two platform windows (perhaps a
new window is created when certain reconfigurations take
place?) and leaving the old one behind? Hmmm.. Here's what
I see with my latest run:
00000D48 "Blah Blah" TkTopLevel
--00000D6C "*" TkChild
----00000CCC "*" TkChild
------00000CD0 "*" Static
------00000DA8 "*" TkChild
00000D54 "combotopxxxx" TkTopLevel
--00000D20 "*" TkChild
----00000CD4 "*" ScrollBar
----00000CC0 "*" ScrollBar
00000D4C "combotopxxxx" TkTopLevel (this is the one crashing)
00000D90 "TEST" TkTopLevel (this is the .exe i'm debugging)
--00000D60 "*" TkChild
----00000CC8 "*" Button
----00000DA0 "*" Button
00000DB0 "Console" TkTopLevel
--00000DAC "*" TkChild
----00000D5C "*" ScrollBar
----00000D68 "*" TkChild
----------------------------------------------------------------------
Comment By: Michael Kirkham (muonics)
Date: 2003-07-07 09:13
Message:
Logged In: YES
user_id=498198
Oh, one other probably important note: this was using Tcl/Tk
8.4.3.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=112997&aid=767176&group_id=12997

Bugs item #767176, was opened at 2003-07-07 09:12
Message generated for change (Comment added) made by muonics
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=112997&aid=767176&group_id=12997
Category: 68. Win Window Operations
Group: 8.4.3
Status: Open
Resolution: None
Priority: 8
Submitted By: Michael Kirkham (muonics)
Assigned to: Chengye Mao (chengyemao)
Summary: Bad winPtr->window pointer causes crash in Tk_GetHWND
Initial Comment:
This is a somewhat obscure and intermitted crash,
demonstrated by the attached script which requires
Bryan Oakley's combobox implementation (demonstrated
with version 2.2.1). An access violation occurs when
WmProc() in tkWinWm.c gets called with a WM_ACTIVATEAPP
event. This isn't in the switch so it goes on to get
winPtr:
winPtr = GetTopLevel(hwnd);
Unfortunately, the value sometimes comes up bogus
(filled with bad pointers and such) and when it
subsequently calls Tk_GetHWND(winPtr), it crashes from
winPtr->window being a bad pointer when attempting to
get winPtr->window.handle.
After lots of experimentation, I was able to cause the
crash with a straight wish running the script (as
opposed to the extended wish plus other Tcl code for my
application, which originally seemed partly involved
due to the intermittent nature of the crash) .
For convenience I've made the buttons take up the huge
area of the main toplevel (.), but that doesn't matter
for demonstrating the crash -- it just keeps you from
having to move the mouse around a bunch. The crash
does, however, seem to involve some of the geometry
operations going on to center and size the various
windows, combined with the combobox and the window
icon. Commenting out any one of these *seems* to stop
the crash from happening, but since it's intermittent
it is hard to be sure. In case it matters, I'm also
attaching the icon I'm using.
To demonstrate, after launching the script, click the
button that says "Combo". A new toplevel will be
created, centered on the screen, with a combobox in it.
Close the window (click the [X] icon). It seems to
occur more often if you repeat this (click the "Combo"
button, close the window that pops up) a couple times.
Then click exit. Often, but not always, this will
crash (with an invalid page fault or an access
violation depending on whether or not
you're running wish from within DevStudio). After
rebuilding wish with debugging symbols and running from
DevStudio I was able to track the crash to the WmProc()
and Tk_GetHWND().
----------------------------------------------------------------------
>Comment By: Michael Kirkham (muonics)
Date: 2003-07-09 05:28
Message:
Logged In: YES
user_id=498198
Poking around with the VC++ debugger and Spy++, I've been
able to figure out that the HWND receiving the
WM_ACTIVATEAPP event is that of the transient toplevel for
the combobox (that's displayed when you hit the little down
arrow button to show the list). Sort of. Curiously, Spy++
shows show TkToplevel's with the name I changed that
transient to (instead of .top, for debugging). One with
children, one without. It would seem that the problem is
either some race condition, something is being left
incomplete about the destruction of this transient toplevel
when the toplevel containing the combobox is destroyed, or
for some reason Tk creates two platform windows (perhaps a
new window is created when certain reconfigurations take
place?) and leaving the old one behind? Hmmm.. Here's what
I see with my latest run:
00000D48 "Blah Blah" TkTopLevel
--00000D6C "*" TkChild
----00000CCC "*" TkChild
------00000CD0 "*" Static
------00000DA8 "*" TkChild
00000D54 "combotopxxxx" TkTopLevel
--00000D20 "*" TkChild
----00000CD4 "*" ScrollBar
----00000CC0 "*" ScrollBar
00000D4C "combotopxxxx" TkTopLevel (this is the one crashing)
00000D90 "TEST" TkTopLevel (this is the .exe i'm debugging)
--00000D60 "*" TkChild
----00000CC8 "*" Button
----00000DA0 "*" Button
00000DB0 "Console" TkTopLevel
--00000DAC "*" TkChild
----00000D5C "*" ScrollBar
----00000D68 "*" TkChild
----------------------------------------------------------------------
Comment By: Michael Kirkham (muonics)
Date: 2003-07-07 09:13
Message:
Logged In: YES
user_id=498198
Oh, one other probably important note: this was using Tcl/Tk
8.4.3.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=112997&aid=767176&group_id=12997

Bugs item #760872, was opened at 2003-06-26 01:52
Message generated for change (Comment added) made by dkf
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=760872&group_id=10894
Category: 44. Parsing and Eval
Group: 8.4.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Don Porter (dgp)
>Assigned to: Don Porter (dgp)
Summary: ellipsis logic is not Unicode-safe
Initial Comment:
Tcl_LogCommandInfo truncates
messages added to the ::errorInfo
variable to at most 150 bytes in
length.
There is no check that this doesn't
break apart a UTF-8 encoded
character.
Seem more sensible to truncate
based on the number of characters
rather than the number of bytes.
Tests init-4.6.* have been committed
to call attention to this problem
There are similar ellipsis issues
in tclProc.c, tclCompile.c, and tclExecute.c.
----------------------------------------------------------------------
>Comment By: Donal K. Fellows (dkf)
Date: 2003-07-09 09:29
Message:
Logged In: YES
user_id=79902
The patch looks OK on the alterations it does make, but code
review (this time, I've looked at everything that matches
".*\.\.\. so I think I've found everything :^/ ) has found
*another* two places that do ellipsis handling which might
matter:
LogSyntaxError() in tclParseExpr.c
TclRegError() in tclRegexp.c
Would it be easier to have a single (internal) Tcl function
to do ellipsis handling and do it right instead of spreading
the logic all over the core?
In Tk, GetEntryText in tkMacOSXMenu.c looks dodgy, but not
UNICODE-dodgy. Just very strange and inefficient (and with
some odd spelling too.) I'm also not 100% sure about
TkpDisplayWarning in tkWinInit.c but that might actually be
OK. However, Tk doesn't seem to do any direct ellipsis
handling, which is good.
----------------------------------------------------------------------
Comment By: Don Porter (dgp)
Date: 2003-07-08 17:58
Message:
Logged In: YES
user_id=80530
updated patch.
----------------------------------------------------------------------
Comment By: Donal K. Fellows (dkf)
Date: 2003-07-07 22:18
Message:
Logged In: YES
user_id=79902
The patch misses a place in tclBasic.c (in function
TclObjInvoke) but otherwise looks fine from a quick glance.
----------------------------------------------------------------------
Comment By: miguel sofer (msofer)
Date: 2003-07-07 21:55
Message:
Logged In: YES
user_id=148712
The patch applies cleanly and passes the testsuite - and
that is as far as my knowledge of unicode things allows me
to judge.
----------------------------------------------------------------------
Comment By: Don Porter (dgp)
Date: 2003-06-27 17:26
Message:
Logged In: YES
user_id=80530
Here's a patch. Please review.
----------------------------------------------------------------------
Comment By: Don Porter (dgp)
Date: 2003-06-27 17:00
Message:
Logged In: YES
user_id=80530
the ellipsis in tclExecute.c and
one of them in tclProc.c just
write directly to stderr
(TCL_COMPILE_DEBUG).
Since they don't store the
truncated string in ::errorInfo,
they are not bugs.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=760872&group_id=10894

Bugs item #767578, was opened at 2003-07-08 08:27
Message generated for change (Comment added) made by henninggodske
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=767578&group_id=10894
Category: 02. Event Loops
Group: 8.4.3
Status: Open
Resolution: None
Priority: 9
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Jeffrey Hobbs (hobbs)
Summary: NotifierThreadProc is spinning on 64 bit machine
Initial Comment:
From
hgo@...
Seen in 8.4.3
The use of vars. "found" and "word" in
NotifierThreadProc() in tclUnixNotfy.c shall be long,
not int,
as they are used to hold long values in the select tests.
This error results in the select spinning if int and long is
not the same size.
First seen on HP-UX 11i running Tcl/Tk in 64 bit mode.
----------------------------------------------------------------------
Comment By: Henning Godske (henninggodske)
Date: 2003-07-09 07:56
Message:
Logged In: YES
user_id=818072
The bug was not found using Tcl/Tk tests, but when
imbedding Tk into another application on a HP-UX 11i.
The Tcl part runs OK, but it started spinning when the main
Tk window was raised, because on the HP platform this sets
a bit in the high-end of the select mask.
The same code was running without any problems on Tru64
UNIX and on Solaris.
So I don't have at test, except that the fix worked on HP-UX
and did not break anything on Tru64 and Solaris.
----------------------------------------------------------------------
Comment By: Jeffrey Hobbs (hobbs)
Date: 2003-07-08 21:24
Message:
Logged In: YES
user_id=72656
I believe going with the proper type is best. Is there a
particular test I can use to verify this (although logically it is
clear ... tests are always nice).
----------------------------------------------------------------------
Comment By: Donal K. Fellows (dkf)
Date: 2003-07-08 10:53
Message:
Logged In: YES
user_id=79902
Any reason not to declare those variables as fd_mask
instead? That's the official type of the members of the
array that they are manipulating...
In fact, I think those variables ought to be declared much
closer to where they are used (somewhere around line 971)
but that's just a general stylistic point.
----------------------------------------------------------------------
Comment By: Henning Godske (henninggodske)
Date: 2003-07-08 08:45
Message:
Logged In: YES
user_id=818072
The code change needed ín tcl8.4.3/unix/tclUnixNotfy.c is:
865c865,866
< int i, status, index, bit, numFdBits, found, receivePipe,
word;
---
> int i, status, index, bit, numFdBits, receivePipe;
> long found, word;
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=767578&group_id=10894

Community

Help

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

I agree to receive quotes, newsletters and other information from sourceforge.net and its partners regarding IT services and products. I understand that I can withdraw my consent at any time. Please refer to our Privacy Policy or Contact Us for more details