Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
For bugs related to Red Hat Enterprise Linux 3 product line. The current stable release is 3.9. For Red Hat Enterprise Linux 6 and above, please visit Red Hat JIRA https://issues.redhat.com/secure/CreateIssue!default.jspa?pid=12332745 to report new issues.

Bug 123158

Summary: "ypserv -p 834" segfaults
Product: Red Hat Enterprise Linux 3 Reporter: Matthew Foulkes <wmc.foulkes>
Component: ypservAssignee: Steve Dickson <steved>
Status: CLOSED CURRENTRELEASE QA Contact: Jay Turner <jturner>
Severity: medium Docs Contact:
Priority: medium    
Version: 3.0CC: dwagelaar, john, smj, srevivo
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-03-28 13:15:49 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Matthew Foulkes 2004-05-13 10:53:09 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.2)
Gecko/20040301

Description of problem:
On an up to date installation of RHEL AS3 on a Proliant server with an
Intel(R) Pentium(R) III CPU - S 1400MHz CPU, the command

  ypserv -p 834

crashes with a segmentation fault. The alternative syntax

  ypserv --port 834

works fine.  According to the ypserv man page, both should work,
although the "-p" version that causes the segfault is given more
prominence. If the "-p" syntax is no longer supported, it should
produce an error message, not a segfault, and the man page should be
updated.

Version-Release number of selected component (if applicable):
ypserv-2.8-6

How reproducible:
Always

Steps to Reproduce:
1. Stop all NIS services
2. Run the command "ypserv -p 834"
3.
    

Actual Results:  The YP server failed to start, producing a
"segmentation fault" error message.

Expected Results:  The YP server should have started.

Additional info:

Although "ypserv -p 834" fails, "ypserv --port 834" works OK.

An alternative way to cause the problem is to add the line 

  YPSERV_ARGS="-p 834"

to /etc/sysconfig/network and run "service ypserv start".

Comment 1 Norman Elton 2004-05-24 16:04:59 UTC
I can confirm this on my system as well. Not good.

Comment 2 John Leach 2004-06-07 14:48:11 UTC
I can confirm this on my system too.  --port worked fine but -p
results in a segfault.
ltrace shows a NULL pointer finding it's way into __strtol_internal()

[root@sql1 root]# ltrace ypserv -p 740
__libc_start_main(...)
openlog("ypserv", 1, 24)                                             
       
getopt_long(...) 
__strtol_internal(NULL, NULL, 10 <unfinished ...>
--- SIGSEGV (Segmentation fault) ---
+++ killed by SIGSEGV +++


[root@sql1 root]# ltrace ypserv --port 740
__libc_start_main(...)
openlog("ypserv", 1, 24)                                             
      
getopt_long(...)
__strtol_internal("740", NULL, 10)                                   
       
getopt_long(...)
fork()                                                               
       
exit(...)
+++ exited (status 0) +++




Comment 3 Theron Toomey 2004-07-20 13:50:17 UTC
I can confirm this behavior too. Thanks for the '--port' workaround.


Comment 4 Dennis Wagelaar 2004-07-28 11:27:44 UTC
*** Bug 128695 has been marked as a duplicate of this bug. ***

Comment 5 Shawn M. Jones 2004-09-05 02:20:08 UTC
I appreciate the --port workaround.  I've noted this in both RHEL 3
and FC 2.

Comment 6 Charles C. Figueiredo 2005-03-24 16:00:03 UTC

This looks like bug #137660 -- update to ypserv-2.8-11...

-charles.

Comment 7 Matthew Foulkes 2005-03-24 16:27:42 UTC
Yes, looks as if Ion Badulescu encountered the same bug about six months after
me and was clever enough to find a fix. Thanks Ion. I am glad that the problem
has been fixed, but disappointed that such a serious bug (which, if it had not
been for the far from obvious --port workaround, would have broken all attempts
to firewall NIS) received no response from Red Hat.