#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).

     

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

Sign up for the SourceForge newsletter:





No, thanks