Menu

#3602 tclUnixChan.c fails to compile on BSD

obsolete: 8.5b3
closed-fixed
8
2007-12-18
2006-12-18
Anonymous
No

Tcl 8.4.14

Suse Linux 9.2 (running as a VMware Workstation 5.5.3 guest OS on a Windows XP Service Pack 2 host OS).

> ./configure --enable-threads
> make
> make test
...
==== http-4.15 http::Event FAILED
...
---- Result was:
1 0
---- Result should have been (exact matching):
11

When running "make test" with threads enabled (i.e. compiled with "-DTCL_THREADS=1 -DHAVE_GETHOSTBYNAME_R_6=1"), I get the above test failure. This does not happen with Tcl 8.5a6, as I'll explain later.

The problem appears to stem from the behavior of gethostbyname_r() (see tcl/unix/tclUnixCompat.c line 589). For my version of Linux (Suse 9.2), gethostbyname_r() returns 0 for both valid and invalid URL's. However, the fifth parameter (struct hostent **RESULT) returns a NULL for invalid URL's. Therefore, a potential fix would be to change "&tsdPtr->hent" on line 591 to use the value returned by the fifth parameter "hePtr", e.g.:

return (gethostbyname_r(name, &tsdPtr->hent, tstPtr->hbuf,
sizeof(tsdPtr->hbuf), &hePtr, &h_errno) == 0) ?
&tsdPtr->hent : NULL;

should be:

return (gethostbyname_r(name, &tsdPtr->hent, tstPtr->hbuf,
sizeof(tsdPtr->hbuf), &hePtr, &h_errno) == 0) ?
hePtr : NULL;

This problem occurs in Tcl 8.4.14 when threads are enabled because tcl/unix/tclUnixChan.c:CreateSocketAddress() invokes the supposedly thread-safe function tcl/unix/tclUnixCompat.c:TclpGetHostByName(), which then invokes gethostbyname_r() if HAVE_GETHOSTBYNAME_R_6 is defined.

This problem does not occur in Tcl 8.5a6 because tclUnixChan.c:CreateSocketAddress() was modified to call the potentially thread-unsafe gethostbyname() function, which may be another problem.

Larry Wright
larry.wright@itron.com

Discussion

  • Jeffrey Hobbs

    Jeffrey Hobbs - 2007-06-10
    • assigned_to: hobbs --> vasiljevic
    • priority: 5 --> 7
     
  • Larry Wright

    Larry Wright - 2007-06-11

    Logged In: YES
    user_id=1671459
    Originator: NO

    Category should be "Tcl", not "http".

     
  • Donal K. Fellows

    • labels: 105670 --> 27. Channel Types
    • assigned_to: vasiljevic --> hobbs
    • priority: 7 --> 9
     
  • Jeffrey Hobbs

    Jeffrey Hobbs - 2007-11-13
    • assigned_to: hobbs --> vasiljevic
     
  • Donal K. Fellows

    Logged In: YES
    user_id=79902
    Originator: NO

    I think it's safer to say that Tcl 8.5 hasn't had the fixes that 8.4 has had in this area, and is thus thread-unsafe!

     
  • Donal K. Fellows

    Logged In: YES
    user_id=79902
    Originator: NO

    HEAD now doesn't use gethostbyname() directly.
    Both HEAD and 8.4 do the 6-arg form correctly.

     
  • Donal K. Fellows

    • assigned_to: vasiljevic --> dkf
    • status: open --> closed-fixed
     
  • Don Porter

    Don Porter - 2007-11-26
    • status: closed-fixed --> open-fixed
     
  • Donal K. Fellows

    • assigned_to: dkf --> dgp
    • priority: 9 --> 7
     
  • Donal K. Fellows

    Logged In: YES
    user_id=79902
    Originator: NO

    Can't see how the reported fix applies. Can't work on it now either (in an airport!). Their #1 fix might be to disable getaddrinfo() support on that platform when building Tcl.

     
  • Don Porter

    Don Porter - 2007-12-03

    Logged In: YES
    user_id=80530
    Originator: NO

    confirmed by "RockShox"

     
  • Don Porter

    Don Porter - 2007-12-03
    • summary: http.test-4.15 http::Event FAILED --> tclUnixChan.c fails to compile on BSD
    • priority: 7 --> 9
    • milestone: 595232 --> obsolete: 8.5b3
     
  • Don Porter

    Don Porter - 2007-12-03
    • assigned_to: dgp --> dkf
     
  • Don Porter

    Don Porter - 2007-12-03

    Logged In: YES
    user_id=80530
    Originator: NO

     
  • Donal K. Fellows

    Logged In: YES
    user_id=79902
    Originator: NO

    Should now be fixed...

     
  • Donal K. Fellows

    • priority: 9 --> 8
    • status: open-fixed --> pending-fixed
     
  • SourceForge Robot

    • status: pending-fixed --> closed-fixed
     
  • SourceForge Robot

    Logged In: YES
    user_id=1312539
    Originator: NO

    This Tracker item was closed automatically by the system. It was
    previously set to a Pending status, and the original submitter
    did not respond within 14 days (the time period specified by
    the administrator of this Tracker).