On 5/31/07, leon zadorin <[email protected]<mailto:[email protected]>> wrote:
OK, the next thing would be to do something like the following: whilst the "frozen" vic is running and "trying to receive DV", use "ps aux" to find out the frozen vic's PID (process id); then strace -pPID This will give you the status of any system calls that vic may be making at a time... If the last message is "futex waiting" and that's it (when vic is on a very little cpu usage) then see below :-) Yeah, when it's not using much CPU it's either running through a bunch of gettimeofday and recvfrom calls or hanging on futex(0x88c16b8, FUTEX_WAIT, 2, NULL On the sending machine it doesn't hang on anything. Interesting :-) We did have an interesting issue with Ubuntu (and only Ubuntu ;-) ... but we were only able to replicate it when starting vic from AG (python environment) and we didn't have enough time to determine what it was (python 2.5 vs 2.4, Ubuntu vs Fedora vs Slackware, 64bit vs 32bit architecture, vic, etc.) The problem was replicated with the old vic as well so I was leaning towards thinking that it was a system-related issue... The problem was two-fold: a) either vic would be taking 100% of CPU and strace would indicate "poll/select" calls being made all the time (e.g . as if the file descriptors that vic was using for socket i/o, etc. got messed up by the hosting system); I know the lack of 100% cpu usage means this probably isn't the case, but for what it's worth there were no polls or selects when I did a 30 second or so strace. b) or vic would be taking virtually no CPU and strace would show "futex waiting" messages... Sometimes "b" would come after "a"... (as if, eventually, reading from the wrong file descriptor got to a "dead lock"). The only system that it was happening (from my shaky memory banks :-) was 64bit Ubuntu Feisty Fawn (kernel 2.6.20) running python 2.5... By the way - what Linux distro is running on the sending machine? Same as the receiver (these are both 32bit by the way), which makes me think that the futex hanging thing is due to the worse video hardware somehow. 233.45.67.88/23456<http://233.45.67.88/23456> with TTL 16 (I may need to increase it - but see how it goes :-) You might want to turn the ttl up, I didn't see any streams on there when I checked Friday afternoon. Just checking 1 more thing :-) In the above example, I was meaning to redirect standard AND error outputs of vic (hence 2>&1)... but this would depend on the shell you are running, so perhaps doing script ./vic YOUR-IP/PORT then CTRL-D after a few seconds (in the terminal) - this should generate a typescript file which will automatically include standard error output... - otherwise, the leonlog2 file may have some missing info... When I do that, there's no error output in the file, just the standard out that I always see on the terminal. One auxiliary thing: what is the display depth of your Xorg (it is indicated as being defaulted to 24bpp in your xorg) - but just to make sure that it is what being used at vic's runtime... (currently we only support hi and true color resolutions)... Yeah, Xorg is running at 24-bit. --Andrew
