bugGNU Octave - Bugs: bug #51830, gethostname and uname nodename...

 
 

bug #51830: gethostname and uname nodename return "localhost"

Submitter:  Marshall <marsian>
Submitted:  Wed 23 Aug 2017 07:33:37 PM UTC
   
 
Category:  Octave Function Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Fixed Assigned to:  None
Originator Name:  Marsian Open/Closed:  * Closed
Release:  * dev Operating System:  * Microsoft Windows
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sat 02 Sep 2017 02:38:51 AM UTC, comment #36: 

I now see that jwe posted on bug-gnulib about this very issue a year ago

https://lists.gnu.org/archive/html/bug-gnulib/2016-06/msg00066.html

I'm not following the logic of the patch at the moment or understanding why that patch used to work but stopped working at some point. But now that we've found the underlying issue and fixed Octave's configure, we might be able to drop src/default-octave-1-gnulib.patch. I'll try to remember to look at that someday.

We might also want to patch stable-octave so that it DTRT, in case there is a need to build another stable release.

Mike Miller <mtmiller>
Group Member
Sat 02 Sep 2017 01:23:13 AM UTC, comment #35: 

Both work on both GUI and CLI for me with a 64 bit build

John Donoghue <lostbard>
Group Member
Fri 01 Sep 2017 02:03:28 AM UTC, comment #34: 

In my cross-build log I can see that libgnu/gethostname.o is now included in the build, so this should work. Let's wait for someone to actually test both gethostname and uname on Windows, both GUI and CLI, to be sure.

Mike Miller <mtmiller>
Group Member
Thu 31 Aug 2017 11:20:31 PM UTC, comment #33: 

I checked in the following changeset so that we are no longer adding -lws2_32 to the LIBS variable in the configure script and instead rely entirely on gnulib to provide dirent.h and the related directory handling functions.

http://hg.savannah.gnu.org/hgweb/octave/rev/3a07616e660b

I haven't checked yet to see whether this avoids the problem with gethostname or uname on Windows systems, but I think it should.

John W. Eaton <jwe>
Group administrator
Thu 31 Aug 2017 12:24:15 AM UTC, comment #32: 

I think calling urlread should also work around this until we work out a proper fix.

Mike Miller <mtmiller>
Group Member
Thu 31 Aug 2017 12:21:25 AM UTC, comment #31: 

I found something that reliably makes uname.nodename to return the correct name even if the same Octave instance gave localhost before. It's a strange work around, but here it is:  If I go to the menu and open News->Community News, then the next (and folllowing) calls to uname work.

Marshall <marsian>
Wed 30 Aug 2017 07:30:12 PM UTC, comment #30: 

Confirmed here, building with the default --enable-windows-64, the gethostname test passes, so the gnulib wrapper is not used. Building with --disable-windows-64, the gethostname test fails, so the gnulib wrapper is used. And I think this all has to do with the order of libraries, different depedencies between the two different msys runtimes maybe, and the fact that we are adding -lws2_32 by default on Windows builds.

Mike Miller <mtmiller>
Group Member
Wed 30 Aug 2017 07:17:46 PM UTC, comment #29: 

Mike: Yes, if gnulib actually does correctly provide replacements for those functions on Windows systems now.

John W. Eaton <jwe>
Group administrator
Wed 30 Aug 2017 06:12:31 PM UTC, comment #28: 

I have log files from 4.2.0, 4.2.1, and 4.3.0+ now, I'll try a fresh build of 4.3.0+ for 32-bit Windows next and see if the same results follow.

Mike Miller <mtmiller>
Group Member
Wed 30 Aug 2017 05:59:05 PM UTC, comment #27: 

You might be right about 32-bit vs 64-bit, someone should try building each and compare results with the same mxe-octave state and the same octave revision.

Here's what your config.log says


configure:61378: checking for gethostname
configure:61378: i686-w64-mingw32-gcc -std=gnu11 -o conftest.exe -g -O2 -pthread -fopenmp -I/home/johnd/mxe-octave/build-qt4/usr/i686-w64-mingw32/include -Wl,-rpath-link,/home/johnd/mxe-octave/build-qt4/usr/i686-w64-mingw32/lib -L/home/johnd/mxe-octave/build-qt4/usr/i686-w64-mingw32/lib -L/home/johnd/mxe-octave/build-qt4/usr/i686-w64-mingw32/lib conftest.c -lm   -lgdi32 -lws2_32 -luser32 -lkernel32 -lgdi32 -lws2_32 -luser32 -lkernel32 >&5
/tmp/ccXHZXwc.o: In function `main':
/home/johnd/mxe-octave/build-qt4/tmp-stable-octave/octave-4.2.0/.build/conftest.c:350: undefined reference to `gethostname'
collect2: error: ld returned 1 exit status
configure:61378: $? = 1
configure:61378: result: no


and here's mine with the same test, only difference is compiling for 64-bit:


configure:61378: checking for gethostname
configure:61378: x86_64-w64-mingw32-gcc -std=gnu11 -o conftest.exe -g -O2 -pthread -fopenmp -I/home/mike/src/octave/mxe-octave/usr/x86_64-w64-mingw32/include -Wl,-rpath-link,/home/mike/src/octave/mxe-octave/usr/x86_64-w64-mingw32/lib -L/home/mike/src/octave/mxe-octave/usr/x86_64-w64-mingw32/lib -L/home/mike/src/octave/mxe-octave/usr/x86_64-w64-mingw32/qt5/lib conftest.c -lm   -lgdi32 -lws2_32 -luser32 -lkernel32 -lgdi32 -lws2_32 -luser32 -lkernel32 >&5
configure:61378: $? = 0
configure:61378: result: yes


After the test fails on 32-bit, the followup test then passes:


configure:61386: checking for gethostname in winsock2.h and -lws2_32
configure:61418: i686-w64-mingw32-gcc -std=gnu11 -o conftest.exe -g -O2 -pthread -fopenmp -I/home/johnd/mxe-octave/build-qt4/usr/i686-w64-mingw32/include -Wl,-rpath-link,/home/johnd/mxe-octave/build-qt4/usr/i686-w64-mingw32/lib -L/home/johnd/mxe-octave/build-qt4/usr/i686-w64-mingw32/lib -L/home/johnd/mxe-octave/build-qt4/usr/i686-w64-mingw32/lib conftest.c -lm   -lgdi32 -lws2_32 -luser32 -lkernel32 -lgdi32 -lws2_32 -luser32 -lkernel32 -lws2_32 >&5
configure:61418: $? = 0
configure:61426: result: yes


The important difference appears to be that "-lws2_32" is appended to the end of the list of libraries.

Mike Miller <mtmiller>
Group Member
Wed 30 Aug 2017 05:40:46 PM UTC, comment #26: 

The compile for octave in mxe-octave puts a copy of the log in the octave etc directory, which also gets installed in when mxe-octave does.

Mine attached for 4.2.0 as a 7z file



(file #41700)

John Donoghue <lostbard>
Group Member
Wed 30 Aug 2017 05:40:09 PM UTC, comment #25: 

Maybe, are you suggesting we delete that block "OS-specific test for dirent, opendir" and use gnulib if needed for those functions?

Mike Miller <mtmiller>
Group Member
Wed 30 Aug 2017 05:35:13 PM UTC, comment #24: 

Shouldn't we be using gnulib for opendir, closedir, readdir, and rewinddir?  I think there may have been a time when gnulib didnot provide those functions for Windows, but now it seems that it does.

John W. Eaton <jwe>
Group administrator
Wed 30 Aug 2017 05:25:28 PM UTC, comment #23: 

If we can't figure this out we could always override the config cache like we do for other cross-compiled functions. Just add ac_cv_func_gethostname=no and gl_cv_w32_gethostname=yes to the set of variables we precondition the configure script with.

Mike Miller <mtmiller>
Group Member
Wed 30 Aug 2017 05:22:07 PM UTC, comment #22: 

Does anyone happen to have a full config.log file from an Octave 4.2.0 mxe-octave build when the gethostname wrapper was used? I would like to compare it to the checks that are in the config.log I just got. Unfortunately the only way to save the log file is to make a copy of tmp-stable-octave/octave-4.2.0/.build/config.log while the build is still going.

I now see that we have some code in configure.ac that adds -lws2_32 to the default LIBS when building for Windows systems, and it has been there for quite a while. That's why I would like to see the full compiler command line that 4.2.0 configure was running when it determined that gethostname does not exist.

Mike Miller <mtmiller>
Group Member
Wed 30 Aug 2017 05:14:45 PM UTC, comment #21: 

I also notice (and may be a redherring) that my 4.2.0 and 4.0.3 are box 32bit builds, whereas my 4.2.1 and dev are 64bit

comment #3 is also 32 vs 64.

John Donoghue <lostbard>
Group Member
Wed 30 Aug 2017 05:06:48 PM UTC, comment #20: 

I just started a new mxe-octave build with stable-octave reverted to 4.2.0, everything else current. The build log looks the same as 4.2.1 to me:


$ grep -i gethostname log/stable-octave
checking for gethostname... yes
checking whether gethostname is declared without a macro... no
      -e 's/@''GNULIB_GETHOSTNAME''@/1/g' \
      -e 's|@''HAVE_GETHOSTNAME''@|1|g' \


So I don't see the same 4.2.0 configuration as you saw in your log file. Could this be due to some other change in mxe-octave, maybe the msys update or some other core library updates?

Anyway, I think this hints that gethostname works when we use the gnulib wrapper, but not when we don't. And maybe something has changed in the cross-build environment so that the function is now detected as being present and ok to use, but it still suffers from this bug of needing to call WSAStartup before use.

If I understand the gnulib gethostname.m4 module correctly, they are testing to see if gethostname exists with no extra libraries linked in, this is the normal POSIX case. Then they are testing if gethostname exists after linking with -lws2_32. If that's the case, then it uses the gnulib wrapper function to initialize gethostname correctly.

The problem appears to be that all configure tests are being run with -lws2_32 added to the default set of libs. This tricks configure into thinking that gethostname is a standard library function, no additional libs needed, and it doesn't use the wrapper.

So how or why is -lws2_32 being added to the default LIBS variable in the mxe-octave cross-build now, was that intentional, is there something we can do in mxe-octave to undo that? If not, is there a way to improve the gnulib check so that the wrapper is used when needed even if the default libs already include -lws2_32?

Mike Miller <mtmiller>
Group Member
Wed 30 Aug 2017 03:27:57 PM UTC, comment #19: 

4.0.3: both uname and gethostname work correctly in gui and cli.

4.2.0: both uname and gethostname work correctly in gui and cli.

4.2.1: uname works in gui, gethostname fails in gui, both fail in cli.

4.3.0: uname works in gui, gethostname fails in gui, both fail in cli.


John Donoghue <lostbard>
Group Member
Wed 30 Aug 2017 03:14:53 PM UTC, comment #18: 

When you said you always get localhost in the CLI, is that with both of Octave's gethostname and uname functions?

I don't see a gethostname.o in my last stable-octave build log either (4.2.1 vs 4.2.1). We did update gnulib between 4.2.0 and 4.2.1, but I don't see any changes in gnulib that stand out having to do with gethostname or unistd.

Mike Miller <mtmiller>
Group Member
Wed 30 Aug 2017 03:11:20 PM UTC, comment #17: 

In 4.2.0 after tha fail, there is also a config line of:

checking for gethostname in winsock2.h and -lws2_32 ... yes



John Donoghue <lostbard>
Group Member
Wed 30 Aug 2017 03:06:15 PM UTC, comment #16: 

I was about to say the same thing.

Looking at my build log for default octave, it doesn't appear to using gethostname.c from gnulib

looking at config.h for dev, I see:

checking for gethostname ... yes


for the installed etc/config.h from a 4.2.0  I see:

checking for gethostname ... no

John Donoghue <lostbard>
Group Member
Wed 30 Aug 2017 03:02:42 PM UTC, comment #15: 

I don't think we are using the gnulib gethostname wrapper, I think configure is detecting that it is not necessary. I do not see a libgnu/.libs/gethostname.o in my last mxe-octave build log.

So it looks like we do need to somehow initiate the WSAStartup function before gethostname is called in the gnulib uname replacement. Maybe this should be reported to gnulib rather than making our own workaround?

Mike Miller <mtmiller>
Group Member
Wed 30 Aug 2017 01:43:09 PM UTC, comment #14: 

I created a quick test function grabbing parts of gnulib that might be useful to start with.

If I run it without the initialization of winsock, I get the localhost in CLI, but the GUI is ok.

If I run with winsock initialization, both work ok.

File attached.


(file #41697)

John Donoghue <lostbard>
Group Member
Wed 30 Aug 2017 12:46:44 PM UTC, comment #13: 

Responding to comment #7:  Mike, you are right that uname uses gethostname, but gnulib also provides a wrapper for that.  But ultimately, it does call the Windows gethostname function from -lws2_32.  So either that function is returning localhost, or it is failing.  You could maybe use the debugger or insert some print statements to figure out which.

However, the info from comment #8 makes me think that gethostname is just failing, because "unknown" is what Octave's wrapper for gethostname (octave::sys::get_host_name) will return if the system's gethostname function fails.

So in any case, I don't see how this is an Octave bug unless we are calling gethostname incorrectly.  Otherwise, we are calling a function that is supposed to return the hostname and it fails.  Fix that function and Octave will do what you want.

We have updated gnulib since Octave 4.2 was released.  Have there been any changes in gnulib that could cause this failure to happen more often now?  The code for gnulib's gethostname replacement on Windows systems is:


rpl_gethostname (char *name, size_t len)
{
  int r;

  if (len > INT_MAX)
    len = INT_MAX;
  gl_sockets_startup (SOCKETS_1_1);
  r = gethostname (name, (int) len);
  if (r < 0)
    set_winsock_errno ();

  return r;
}


It doesn't look like this has changed since 4.2.  What happens in gl_sockets_startup?  That function also appears to be unchanged since 4.2, but is it possible that it fails to initialize something such that gethostname subsequently fails?

Can you create a simpler example program that just uses the gnulib functions independently from Octave that also demonstrates this problem?

John W. Eaton <jwe>
Group administrator
Wed 30 Aug 2017 12:16:07 PM UTC, comment #12: 

On my win 10 machine, I am unable to replicate the local host issue (but do see the error message) when running the GUI link.

But when running CLI link, it (so far) always shows as localhost.

John Donoghue <lostbard>
Group Member
Wed 30 Aug 2017 04:22:56 AM UTC, comment #11: 

Just now, opening octave it gave the right answer:

>> [utsname, err, msg] = uname
utsname =

  scalar structure containing the fields:

    sysname = MINGW32_NT-6.2
    nodename = MDF-TreeFrog
    release = Windows 6.2
    version =
    machine = x86_64

err = 0
msg = uname not supported on this system

When closing octave and re-opening it (not opening a second instance at the same time), it gave localhost again. Restarting the computer doesn't always seem to get it to work again: It didn't work this time I tried (after getting localhost).

Marshall <marsian>
Tue 29 Aug 2017 09:47:49 PM UTC, comment #10: 

Marshall - any further details? Are you able to get Octave to report the host name again after restarting or is it now always "localhost"? If you are still seeing the same issue with multiple instances running simultaneously, does the gethostname function exhibit the same behavior?

Avinoam - if you can't get uname or gethostname to report the host name correctly at all with your dev build, but it always works fine in 4.2, then that seems like a completely separate bug. Please do continue to investigate, but let's keep this bug focused on the host name sometimes being right and sometimes being wrong in 4.2.

Mike Miller <mtmiller>
Group Member
Sun 27 Aug 2017 05:55:36 PM UTC, comment #9: 

I have opened a separate bug (bug #51869) for msg not being an empty string (comment #8)

Avinoam Kalma <avinoam>
Group Member
Fri 25 Aug 2017 10:49:54 PM UTC, comment #8: 

Checking again, I saw that in version 4.2.1 under Win-10,
I always get the correct nodename, and it does not depend on the number of Octave instances (I have tried 1-5).

In 4.3.0+ (dev) I get always "localhost", and again, it does not depend on the number of Octave instances.

In the help of uname I see:
"If successful, ERR is 0 and MSG is an empty string."

On both 4.2.1 & dev, ERR is 0, but MSG is not empty.

There is still a regression problem:

On 4.2.1


>> gethostname
ans = Kalma-PC


On dev:

>> gethostname
ans = unknown


Avinoam Kalma <avinoam>
Group Member
Fri 25 Aug 2017 04:22:40 PM UTC, comment #7: 

Like I said before, the msg only matters if err is non-zero.

So this indicates that the uname function in gnulib is not returning an error. When I look in the code for uname on Windows, it calls the gethostname function to fill in the nodename field, which is part of the Windows API.

If the Windows gethostname function returns with an error, it fills nodename with the string "localhost". So that's as much as I can tell at this point.

Can you also try gethostname with multiple running instances of Octave, along with uname, to see if it has the same behavior?

Can you not get Octave to report the correct host name at all now?

Avinoam - was your test also with multiple instances of Octave running at the same time? I don't think this is a regression since Marshall sees both good and bad results with version 4.2

Mike Miller <mtmiller>
Group Member
Fri 25 Aug 2017 02:05:57 PM UTC, comment #6: 

I got 'localhost' again. It happened when I opened a second instance of Octave. The first instance continued to give the correct name, but the second and later instances always gave 'localhost' even after closing all open Octave programs. Now I only get 'localhost' again even after hibernating or completely restarting the computer.


>> [utsname, err, msg] = uname
utsname =

  scalar structure containing the fields:

    sysname = MINGW32_NT-6.2
    nodename = localhost
    release = Windows 6.2
    version =
    machine = x86_64

err = 0
msg = uname not supported on this system


But err and msg are the same whether it gives the correct response or not.

Marshall <marsian>
Fri 25 Aug 2017 01:53:59 PM UTC, comment #5: 

Of course, since reporting the bug, I haven't been able to get the 'localhost'  response, but I had waited to report it until both machines were giving 'localhost'. Both machines are on 4.2.1.
I do see 'uname not supported on this system' for the msg return argument when it is successful.

Marshall <marsian>
Fri 25 Aug 2017 06:26:46 AM UTC, comment #4: 

Note also that if the result of


     err = octave_uname_wrapper (&sysname, &nodename, &release,
                                  &version, &machine);


from oct-uname.cc, err = 0, the msg field is not changed, and  we still get the original error message


uname not supported on this system


from oct-uname.h.

Avinoam Kalma <avinoam>
Group Member
Fri 25 Aug 2017 05:38:34 AM UTC, comment #3: 

Sorry.

With 4.2.1


>> [utsname, err, msg] = uname
utsname =

  scalar structure containing the fields:

    sysname = MINGW32_NT-6.2
    nodename = Kalma-PC
    release = Windows 6.2
    version =
    machine = i686

err = 0
msg = uname not supported on this system


On dev branch:


>> [utsname, err, msg] = uname
utsname =

  scalar structure containing the fields:

    sysname = MINGW32_NT-6.2
    nodename = localhost
    release = Windows 6.2
    version =
    machine = x86_64

err = 0
msg = uname not supported on this system


So, there seems to be a regression problem here.

Avinoam Kalma <avinoam>
Group Member
Fri 25 Aug 2017 05:32:34 AM UTC, comment #2: 

On Win 7

Avinoam Kalma <avinoam>
Group Member
Thu 24 Aug 2017 12:23:35 AM UTC, comment #1: 

Please try to figure out what set of conditions cause this to happen.

Also try calling uname with 3 output arguments


[utsname, err, msg] = uname


If err is nonzero, then msg should describe the error.

If err is zero and you still get localhost, then this is probably a failure in the gethostname function on Windows, which is outside of the scope of Octave to fix. If you can come up with a reproducible test case, it might be worth reporting to gnulib. We can help you debug this and work up a minimal test case for gnulib, but other than that it's probably not something Octave can do anything about.

Mike Miller <mtmiller>
Group Member
Wed 23 Aug 2017 07:33:37 PM UTC, original submission:  

I have been using uname.nodename recently to run different options depending on the computer the code is running on. I have found that sometimes it gives the pc name correctly, but other times it only gives "localhost". I can't track down yet what causes it, whether it is how Octave is started, or some other network settings... I have seen this on two different machines where it correctly gave the pc name, but then later only gave "localhost".

Marshall <marsian>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #41700:  config.7z added by lostbard (84KiB - application/octet-stream)
file #41697:  myuname.cc added by lostbard (2KiB - text/plain)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by lostbard (Posted a comment)
  • -email is unavailable- added by avinoam (Posted a comment)
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by marsian (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 11 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2017-09-02 mtmiller StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2017-08-31 jwe StatusConfirmed Ready For Test
    2017-08-30 lostbard Attached File- Added config.7z, #41700
    2017-08-30 mtmiller Summaryuname nodename sometimes gives &quot;localhost&quot; instead of pc name gethostname and uname nodename return "localhost"
    2017-08-30 lostbard Attached File- Added myuname.cc, #41697
    2017-08-25 mtmiller Item GroupRegression Incorrect Result
    2017-08-25 avinoam Release4.2.1 dev
    2017-08-25 avinoam Item GroupIncorrect Result Regression
        StatusNeed Info Confirmed
    2017-08-24 mtmiller StatusNone Need Info

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code