package req Tk
tk_getOpenFile
consistently generates a crash in less than a minute. To generate the
crash, spend some time in the file dialog. For example, use the back
arrow and up-arrow to navigate the directories or go back and forth
between two directories. Be slow and hover your cursor idly on file
names. (You may need to select a file, hit OK, then run
tk_getOpenFile again.) Suddenly, the whole application crashes.
Sometimes it crashes pretty quickly, just after displaying the window
but before the user can see what is in it; other times it takes a few
seconds.
This is on Windows XP, Tcl/Tk 8.4.19. But the situation has persisted
at least since 8.4.11. Here is a link to the original thread from a
couple of years ago.
AppName: wish84.exe AppVer: 8.4.2.19 ModName: shell32.dll
ModVer: 6.0.2900.3241 Offset: 000915ce
FWIW, I can't reproduce it even after several minutes of interaction
with the file dialog. It withstands both slow and fast interaction.
Windows XP SP2 with ActiveTcl 8.4.14.
I was unable to reproduce this on my Vista SP1 machine.
Have you been able to reproduce this on a DIFFERENT Windows XP machine?
Maybe something on that particular machine is causing the issue?
I can only join the chorus:
With both Tcl 8.4.12 and 8.5.2 it works okay on my Windows XP machine.
(Both using tclsh and wish by the way with the two commands
you used)
Have you tried starting in a _different_ directory or a different
disk? What happens if you do a [glob *] ?
Regards,
Arjen
uwe
There is a SF bug on this and it was shown that one of the Adobe shell
extensions was actually the root cause. It doesn't effect just Tk
(the right google search, noted in the bug, points to others having
the issue).
Jeff
I have seen on it different machines and our users are seeing it on
their machines. It is very upsetting for them.
Yes, it is. At the time, Gerald Lester was able to reproduce it. But
no one else did. Since I know how to cause it to crash, I can
reproduce it consistently within a minute.
> There is a SF bug on this and it was shown that one of the Adobe shell
> extensions was actually the root cause. It doesn't effect just Tk
> (the right google search, noted in the bug, points to others having
> the issue).
>
> Jeff
Do you have a link to this? I wonder if there is some sort of
solution or work-around?
I can't remember for sure, but I think getting rid of out of date
versions of Acrobat Reader will clear the problem. (I've seen systems
with five different versions battling it out for the ownership of .PDF)
Donal.
> I can't remember for sure, but I think getting rid of out of date
> versions of Acrobat Reader will clear the problem. (I've seen systems
> with five different versions battling it out for the ownership of .PDF)
I removed Adobe Acrobat Reader altogether. I then tested it. It
seemed to work fine, and it did not crash despite my attempts.
I then downloaded and installed the latest Reader. And when I tested
it again, it crashed right away. Interesting...
I hope there is a solution or a workaround soon.
Get rid of Adobe Acrobat Reader altogether and install GhostView :-).
Or xpdf (I believe there is a MS-Windows version of xpdf, but I am not
sure).
Make sure you have gotten rid of *all* versions of Adobe Acrobat Reader
and then do a clean install of just one version.
>
>
>
--
Robert Heller -- Get the Deepwoods Software FireFox Toolbar!
Deepwoods Software -- Linux Installation and Administration
http://www.deepsoft.com/ -- Web Hosting, with CGI and Database
hel...@deepsoft.com -- Contract Programming: C/C++, Tcl/Tk
While I was able to confirm that Adobe Reader was the shell extension
at fault and see this corroborated by other projects having similar
problems due to Adobe, I never saw how one would work around it. I
believe it really is an outright bug in Adobe's shell extension. If
you look at the code that pops up dialogs in Tk, it is bog standard
usage of the Win32 APIs.
Jeff
> While I was able to confirm that Adobe Reader was the shell extension
> at fault and see this corroborated by other projects having similar
> problems due to Adobe, I never saw how one would work around it. I
> believe it really is an outright bug in Adobe's shell extension. If
> you look at the code that pops up dialogs in Tk, it is bog standard
> usage of the Win32 APIs.
Thanks Jeff. I am trying to learn more and submit a bug report to
Adobe. I have not found the exact match yet but based on my search
results, it seems that other Adobe tools also have similar problems
with file selection crashing their applications.
We were thinking of upgrading to 8.5 but I guess it is not going to
help in this respect.
> Make sure you have gotten rid of *all* versions of Adobe Acrobat Reader
> and then do a clean install of just one version.
I did this and the bug came back. Perhaps, after uninstalling, I
should do a restart?
I may have missed this in the thread but out of curiosity, have you been
able to reproduce the error with other applications (other than Tcl/Tk)
that use the standard Windows Open File dialog?
> I may have missed this in the thread but out of curiosity, have you been
> able to reproduce the error with other applications (other than Tcl/Tk)
> that use the standard Windows Open File dialog?
No, I have not seen in with any other application. The users are the
ones that complain the most. They have not seen this behavior with
other applications either; they just associate it with this script.
A very good question! I wonder why it only (mostly?) affects Tk.
Yes, you need to reboot the machine.
--
+--------------------------------+---------------------------------------+
| Gerald W. Lester |
|"The man who fights for his ideals is the man who is alive." - Cervantes|
+------------------------------------------------------------------------+
It doesn't only affect Tk, but Tk does seem to be sensitive to it.
Mind you, the crash is definitely NOT occurring in any Tk code - it
crashes in the shell32.dll as your original stack trace showed. Tk is
just the victim.
So again though ... why Tk? It may be the way the dialog is
instantiated. You would need to find other apps using the same dialog
style (the Win32 API has numerous options for instantiating
GetOpenFileNameW). You can look at the code in win/tkWinDialog.c and
see the various ways it is called. I'd be happy to provide binaries
with alternate flag compilations. Remember though, the crash doesn't
occur in tk84.dll, it happens in shell32.dll ...
To see that others hit this problem with Adobe shell extensions, see
here:
Jeff
The SF bug for this is I believe #1623567 and that was able to be
reproduced just using notepad.exe
See
http://sourceforge.net/tracker/index.php?func=detail&aid=%201623257&group_id=12997&atid=112997
--
Pat Thoyts http://www.patthoyts.tk/
To reply, rot13 the return address or read the X-Address header.
PGP fingerprint 2C 6E 98 07 2C 59 C8 97 10 CE 11 E6 04 E0 B9 DD