Menu
▾
▴
#3402 Crash when tclWinProcs->getFileAttributesExProc is NULL
closed-invalid
5
2006-04-01
2006-03-29
Anonymous
No
Running a FCMD_EXISTS in Tcl_FileObjCmd:
If tclWinProcs->getFileAttributesExProc is NULL then
the following line in TclpObjNormalizePath will fail:
if ((*tclWinProcs->getFileAttributesExProc)(nativePath,
GetFileExInfoStandard, &data) != TRUE) {
On my Windows 2000 system, this function pointer is
always NULL at the point of failure.
TclWinSetInterfaces (being the only function I can find
that sets this up) doesn't appear to have been called
at this point.
Logged In: NO
You'll have to provide a test script or more detail as to
how you are using Tcl, since this works for me.
Have you tried running Tcl's test suite?
Vince.
Logged In: NO
The test suite works OK.
We have the TCL library embedded in our C/C++ application.
The problem appeared after trying to upgrade the TCL library
from 8.2 to 8.4. I wasn't involved in the original
implementation of our product, so I know little about the
history.
Obviously, I am missing some initialization step that was
either added since 8.2 or is a little more critical now.
I'll check the docs and source code.
You can close this if you like.
Logged In: NO
The test suite works OK.
We have the TCL library embedded in our C/C++ application.
The problem appeared after trying to upgrade the TCL library
from 8.2 to 8.4. I wasn't involved in the original
implementation of our product, so I know little about the
history.
Obviously, I am missing some initialization step that was
either added since 8.2 or is a little more critical now.
I'll check the docs and source code.
You can close this if you like.
Logged In: NO
The test suite works OK.
We have the TCL library embedded in our C/C++ application.
The problem appeared after trying to upgrade the TCL library
from 8.2 to 8.4. I wasn't involved in the original
implementation of our product, so I know little about the
history.
Obviously, I am missing some initialization step that was
either added since 8.2 or is a little more critical now.
I'll check the docs and source code.
You can close this if you like.
Logged In: NO
The problem appeared after trying to upgrade the TCL library
from 8.2 to 8.4. I wasn't involved in the original
implementation of our product, so I know little about the
history.
Obviously, I am missing some initialization step that was
either added since 8.2 or is a little more critical now.
I'll check the docs and source code.
You can close this if you like.
Logged In: NO
Please ignore the multiple comments - problems with the
Internet connection and the back button.
Logged In: YES
user_id=79902
Guessing (with no real experience to back this up ;-)) that
this is a missing Tcl_FindExecutable() call? That's the
entry point that causes the initialization of the Tcl
library, and if you're linking directly you wouldn't notice
the usual way it fails horribly (unconfigured stubs tables).
If the app doesn't call that (or either of the Tcl_Main or
Tk_Main convenience functions, of course) then random
failures inside the guts of Tcl are to be expected...
Logged In: NO
That's it :)
Our application has been like this for years without a
problem. Obviously, this has become critical in 8.4.
I'm not sure whether this will fall over on Windows 95 which
doesn't support GetFileAttributesEx. Unfortunately, we don't
support Windows 95 any more so I haven't got the test
environment here to check it out for you.
Many thanks for your help.
Logged In: YES
user_id=72656
To be clear, Tcl_FindExecutable has been "required" since
8.1 (the addition of i18n support), but only in 8.4 did it
become critical to init some encoding bits correctly.