#3402 Crash when tclWinProcs->getFileAttributesExProc is NULL

obsolete: 8.4.12
closed-invalid
Vince Darley
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.

Discussion

  • 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.

     
  • Vince Darley
    Vince Darley
    2006-04-01

    • status: open --> closed-invalid
     
  • Jeffrey Hobbs
    Jeffrey Hobbs
    2006-04-01

    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.