Bugs item #686928, was opened at 2003-02-14 21:32
Message generated for change (Comment added) made by brechin
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=109368&aid=686928&group_id=9368
Category: Installation
>Group: 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Benoit des Ligneris (bligneri)
>Assigned to: Jason Brechin (brechin)
Summary: Installation wizard frozen when quiiting collecting MAC win
Initial Comment:
The wizard is frozen each time I left the "collect MAC
address & co" pannel.
This happens when the tcpdump is still running.
Works fine when tcpdump is dead. So I think "killall -9
tcpdump" before lefting the pannel will do the job.
More elegant : store the process ID of tcpdump and kill
only this instance of the program.
----------------------------------------------------------------------
>Comment By: Jason Brechin (brechin)
Date: 2003-07-08 11:05
Message:
Logged In: YES
user_id=274641
This should be fixed... especially since you can't click "Close"
until you've stopped collecting (and thus stopped the
tcpdump).
----------------------------------------------------------------------
Comment By: Jeff Squyres (jsquyres)
Date: 2003-02-27 08:21
Message:
Logged In: YES
user_id=11722
The problem is not vmware related. Nor is it related to
opening/closing the networking window like a madman. It
happens even if you open / close the window *once* without
first clicking on "stop collecting macs".
If you look at the code in begin_collect_mac(), the main
loop condition is:
while($COLLECT and $_ = <TCPDUMP>) {
Note that all that clicking on the "stop collecting macs"
button does is set $COLLECT to 0. This is fine if the ping
is still running, and works as expected.
But if you click on the "close" button without clicking on
the "stop collecting macs" button, the ping is killed
immediately. Therefore, the loop condition is left blocking
in the $_ = <TCPDUMP> state (because tcpdump goes silent,
since ping is not there to generate output). Hence, even if
you set $COLLECT to 0, that won't be seen until tcpdump
happens to randomly produce some more output (and this loop
iterates around again) -- which is totally random when that
will happen.
You either need a better loop condition or you need to
change the ordering of the shutdown such that this loop can
guarantee to be finished before you turn off the ping. It's
a classic multi-threaded shutdown synchronization problem.
-----
Moral of the story: stop disregarding bugs reported from
vmware and blaming them on vmware.
----------------------------------------------------------------------
Comment By: Jason Brechin (brechin)
Date: 2003-02-26 22:23
Message:
Logged In: YES
user_id=274641
Well... the ping process id is stored. If it's not set, it doesn't
try to kill it. When it kills the ping, it unsets the process ID.
Perhaps it's having problems killing the ping? Perhaps the
VMWare networking is set up strangely so that pinging the
broadcast address causes problems? I've had intermittent
problems with the ping as it is done now and have resorted to
pinging particular addresses (like the client addresses or the
server's address IIRC) in those cases where I have problems.
Perhaps the address that is pinged should be changed?
Again... I've done installs on various OSs and have not seen
this problem. Then again, I don't open and close the Setup
Networking window like a madman either ;)
----------------------------------------------------------------------
Comment By: Jeff Squyres (jsquyres)
Date: 2003-02-26 22:01
Message:
Logged In: YES
user_id=11722
Upon a little more testing, I think the Tk error is actually
a double click on the "Close" button in the networking
window (it got a double click because it was running so slow
that I was able to click on the button twice before it
actually closed the window). So this is probably not a huge
deal.
But the non-refreshing delay is definitely repeatable -- it
seems to be that the window is trying to kill the background
ping twice, and the big delay is while its trying to kill
the ping the second time. Specifically:
-----
Attempting to kill 14257
--> Step 6: Killed background ping
--> Step 6: Stopped listening to network
--> Step 6: Completed successfully
[...big delay...]
--> Step 6: Killed background ping
------
Once that last line comes up, the main window unfreezes and
all is well. So I'm guessing that there's some code in
there that doesn't detect that the ping is already dead and
the delay is a product of trying to kill it incorrectly.
Should probably be pretty easy to fix.
I'll bet that this wasn't correctly diagnosed before because
the delay is somewhat long (O(30 secs)?), and I'll bet that
Ben and I didn't wait it out before. :-)
----------------------------------------------------------------------
Comment By: Jeff Squyres (jsquyres)
Date: 2003-02-26 21:49
Message:
Logged In: YES
user_id=11722
I have attached an oscarinstall.log showing the problem.
Here's what I did:
- opened networking window
- started collecting macs
- clicked on close
- saw the output saying that it killed the network ping
- main window was frozen (non-refreshing) for about 30
seconds, although it was not busy (i.e., the cursor was the
arrow, not the stopwatch). After about 30 seconds, it
started refreshing and the buttons became responsive.
- repeated the same procedure (in the same run), with the
same results
- repeated the same procedure (in the same run) and got a Tk
error. See the attached oscarinstall.log.
So something is going wrong here, and it doesn't look like
this a vmware issue.
----------------------------------------------------------------------
Comment By: Jason Brechin (brechin)
Date: 2003-02-25 09:36
Message:
Logged In: YES
user_id=274641
Can someone send an oscarinstall.log from an instance of
this happening? I see no case where this could/should
happen. Perhaps it is a VMWare issue? You two (Ben &
Jeff) seem to be the only ones testing with VMWare...
----------------------------------------------------------------------
Comment By: Jeff Squyres (jsquyres)
Date: 2003-02-25 08:04
Message:
Logged In: YES
user_id=11722
FWIW, this happened to me last night when I was collecting
screen shots for the docs. The entire wizard was hung, and
I had to ctrl-C out of it.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=109368&aid=686928&group_id=9368
-------------------------------------------------------
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing & more.
Download & eval WebKing and get a free book.
www.parasoft.com/bulletproofapps
_______________________________________________
Oscar-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/oscar-devel
