bugGNU Wget - Bugs: bug #54178, wget sometimes returns 1024

 
 

bug #54178: wget sometimes returns 1024

Submitter:  J <now3d>
Submitted:  Sun 24 Jun 2018 06:48:09 PM UTC
   
 
Category:  None Severity:  3 - Normal
Priority:  5 - Normal Status:  Inspected
Privacy:  Public Assigned to:  None
Originator Name:  Open/Closed:  Closed
Release:  None Operating System:  None
Reproducibility:  None Fixed Release:  None
Planned Release:  None Regression:  None
Work Required:  None Patch Included:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Tue 03 Jul 2018 10:11:47 AM UTC, comment #8: 

Thank you for your reply

ok, let's close this ticket. Not sure how to do that though.

J <now3d>
Tue 03 Jul 2018 03:33:42 AM UTC, comment #7: 

I'm running Fedora 19.

In any case, the critical part, "In the last two cases, the return value is a "wait status" that can be examined using the macros described in waitpid(2). (i.e., WIFEXITED(), WEXITSTATUS(), and so on)." seems to be functionally the same between your system and mine.

Dale Worley <worley>
Sun 01 Jul 2018 03:23:28 PM UTC, comment #6: 

Hi David

Thank you for you message, I will use WEXITSTATUS(result) as you describe.

BTW, I noticed my Ubuntu LTS machine man page for system(3) looks quite different from yours. I wonder if you are not running GNU/Linux?


RETURN VALUE
       The return value of system() is one of the following:

       *  If command is NULL, then a nonzero value if a shell is available, or
          0 if no shell is available.

       *  If a child process could not be created, or its status could not  be
          retrieved, the return value is -1.

       *  If  a  shell  could  not  be executed in the child process, then the
          return value is as though the  child  shell  terminated  by  calling
          _exit(2) with the status 127.

       *  If  all  system calls succeed, then the return value is the termina‐
          tion status of the child shell used to execute command.  (The termi‐
          nation  status of a shell is the termination status of the last com‐
          mand it executes.)

       In the last two cases, the return value is a "wait status" that can  be
       examined using the macros described in waitpid(2).  (i.e., WIFEXITED(),
       WEXITSTATUS(), and so on).

       system() does not affect the wait status of any other children.

J <now3d>
Sun 01 Jul 2018 02:14:15 AM UTC, comment #5: 

Looking at the manual page for system(3) on my system:

RETURN VALUE
       The value returned is -1 on  error  (e.g.,  fork(2)  failed),  and  the
       return  status  of the command otherwise.  This latter return status is
       in the format specified in wait(2).  Thus, the exit code of the command
       will  be  WEXITSTATUS(status).   In case /bin/sh could not be executed,
       the exit status will be that of a command that does exit(127).

Looking at the manual page for wait(2) on my system:

       WEXITSTATUS(status)
              returns  the  exit  status  of  the child.  This consists of the
              least significant 8 bits of the status argument that  the  child
              specified  in  a  call to exit(3) or _exit(2) or as the argument
              for a return statement in main().  This macro should be employed
              only if WIFEXITED returned true.

Blindly searching through the system *.h files, it appears that, effectively,

#define WEXITSTATUS(status)   (((status) & 0xff00) >> 8)

This suggests that if you want to print the subprocess's exit status, you need to change the printf in wget2.c to:

    printf("wget result: %d\n", WEXITSTATUS(result));

The value of result as an integer isn't fixed by the specification of system(3), only the value of WEXITSTATUS(result).

Dale Worley <worley>
Sat 30 Jun 2018 09:45:15 PM UTC, comment #4: 

Hi
I've attached C code example which invokes "wget". I think you are right, the system() syscall invokes a shell, which invokes wget.. that seems to fork() which is probably why the result is shifted 8bits

(file #44468)

J <now3d>
Tue 26 Jun 2018 12:26:42 PM UTC, comment #3: 

The reported status of 1024 is suspiciously equal to the documented status of 4, shifted up 8 bits.

Dale Worley <worley>
Sun 24 Jun 2018 07:13:46 PM UTC, comment #2: 

$ wget http://beflirty.com/
--2018-06-24 21:08:30--  http://beflirty.com/
Resolving beflirty.com (beflirty.com)... failed: Name or service not known.
wget: unable to resolve host address 'beflirty.com'
$ echo $?
4

See 'man wget' (section EXIT STATUS). 4 is a network failure.

Maybe you can give some more details on how to reproduce 1024.

Tim Ruehsen <rockdaboot>
Group administrator
Sun 24 Jun 2018 06:53:27 PM UTC, comment #1: 

$ wget --version
GNU Wget 1.19.4 built on linux-gnu.

J <now3d>
Sun 24 Jun 2018 06:48:09 PM UTC, original submission:  

When wget can't connect to a server, it would appear it is returning 1024 to bash. Note the site exists, but has no web server, shouldn't wget retur (0) for success and (1) for an error?

--2018-06-24 15:29:32--  http://beflirty.com/
Resolving beflirty.com (beflirty.com)... failed: Name or service not known.
wget: unable to resolve host address ‘beflirty.com’

J <now3d>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #44468:  wget2.c added by now3d (455B - text/x-csrc - test case which shows the problem)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by worley (Posted a comment)
  • -email is unavailable- added by rockdaboot (Posted a comment)
  • -email is unavailable- added by now3d (Submitted the item)
  •  

    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-07-03 rockdaboot StatusNone Inspected
        Open/ClosedOpen Closed
    2018-06-30 now3d Attached File- Added wget2.c, #44468

    Back to the top

    Powered by Savane 3.13-caa5.
    Corresponding source code