#3741 Tcl_FSGetNormalizedPath is hairier monster

obsolete: 8.5a7
open
5
2007-07-11
2007-07-11
Don Porter
No

The most recent commit to tclPathObj.c,
1.62 -> 1.63, causes a crash in the
trofs test suite (test trofs-12.8).

Examining...

Discussion

  • Don Porter

    Don Porter - 2007-07-11
    • assigned_to: kennykb --> dgp
    • status: open --> pending-invalid
     
  • Don Porter

    Don Porter - 2007-07-11

    Logged In: YES
    user_id=80530
    Originator: YES

    Looking like this is really a bug
    in trofs, just exposed by the changes
    to refcount logic. These changes
    appear to have extended (created?)
    a Hairy Monster nature for the
    Tcl_FSGetNormalizedPath routine.

    The pathPtr passed in to
    Tcl_FSGetNormalizedPath has
    fsPathPtr->translatedPathPtr with
    zero refCount. Since the pointer is
    stored, there ought to be a refcount
    to go with that. Still need to look
    it over with care, but that's probably
    trofs's fault.

     
  • Don Porter

    Don Porter - 2007-07-11

    Logged In: YES
    user_id=80530
    Originator: YES

    Nope. trofs never touches that
    field at all. It's the Tcl core
    that permits that field to hold
    a pointer value, but leave the
    Tcl_Obj pointed to with zero refcount,
    apparently due to some very complex
    requirements of some circular reference
    scheme.

     
  • Don Porter

    Don Porter - 2007-07-11
    • assigned_to: dgp --> kennykb
    • status: pending-invalid --> open
     
  • Don Porter

    Don Porter - 2007-07-11

    Logged In: YES
    user_id=80530
    Originator: YES

    Was able to workaround the issue
    with changes to trofs. The code which
    is not safe looks like:

    Tcl_FSGetNormalizedPath(NULL,
    Tcl_FSJoinToPath(parent, 1, &element));

    where T_FSJTP can return a zero
    refcount Tcl_Obj, and T_FSGNP can
    free it just by trying to determine
    its normalized form.

    Probably should add warnings to the
    docs that it's not safe to pass
    zero refcount pathPtr values to
    T_FSGNP().

     
  • Don Porter

    Don Porter - 2007-07-11
    • priority: 9 --> 5
    • summary: new tclPathObj.c crash --> Tcl_FSGetNormalizedPath is hairier monster
     
  • Don Porter

    Don Porter - 2007-07-11

    Logged In: YES
    user_id=80530
    Originator: YES

    Something else to consider is whether
    T_FSGNP ought to immediately panic
    if handed a zero refcount pathPtr.

     

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

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks