Bug 144882 - Arping utility hangs if SIGALRM blocked
Summary: Arping utility hangs if SIGALRM blocked
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: iputils
Version: 3.0
Hardware: i386
OS: Linux
medium
low
Target Milestone: ---
Assignee: Radek Vokál
QA Contact: Mike McLean
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-01-12 14:17 UTC by Atul Verma
Modified: 2007-11-30 22:07 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1085971 (view as bug list)
Environment:
Last Closed: 2005-05-12 08:26:32 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
C file to reproduce the bug (385 bytes, text/plain)
2005-01-12 14:21 UTC, Atul Verma
no flags Details

Description Atul Verma 2005-01-12 14:17:47 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; Texas 
Instruments; .NET CLR 1.1.4322)

Description of problem:
If "arping" utility is forked (using system() library function) from 
a parent process in which SIGALRM signal is blocked then the system() 
function call never returns.

The problem is that arping utility installs a SIGALRM handler but 
does not bother to unblock it - so its logic does not work if it 
inherited blocked SIGALRM.

Version-Release number of selected component (if applicable):
iputils-20020927-11

How reproducible:
Always

Steps to Reproduce:
1.Block SIGALRM signal
2.Call srping utility ising system() library function
3.Observe that system() function never returns
    

Actual Results:  The process hangs forever

Expected Results:  The process should have exited

Additional info:

Comment 1 Atul Verma 2005-01-12 14:21:58 UTC
Created attachment 109666 [details]
C file to reproduce the bug

Comment 2 Radek Vokál 2005-01-17 11:47:18 UTC
This comes from your test C code. I see what you mean with SIGALRM
locked but it works on my machine.

# ./mytest1
Executing command [arping -c 1 -I eth0 192.168.1.1]
ARPING 192.168.1.1 from 192.168.1.13 eth0
Unicast reply from 192.168.1.1 [00:10:4B:6B:18:87]  5.317ms
Sent 1 probes (1 broadcast(s))
Received 1 response(s)
System call returned with status 0

# rpm -q iputils
iputils-20020927-19 (includes updated ifenslave, might fix the issue)



Comment 3 Radek Vokál 2005-05-12 08:26:32 UTC
retested, problem not found


Note You need to log in before you can comment on or make changes to this bug.