DESCRIPTION
-----------
It appears a combination of conditions can cause Maya
under Linux to hang indefinitely during rendering,
using up 99% of the cpu.
The two conditions that have to be met are:
1) If a UNC style path is supplied as either the scene
or project path, or possibly even in texture paths.
(e.g. "//some/path")
2) If a file (eg. texture map) referred to by the scene
file does not exist.
When these two conditions occur, maya.bin starts using 99%
of the cpu when it tries to open the file that does not exist.
Running strace(1) on maya.bin reveals it enters an infinite loop,
trying to open the non-existent file over and over again,
without printing an error. This was reported by Dylan Penhale,
and the following solution was verified to prevent the problem.
Versions of Rush 102.41 or greater have submit scripts that try to
prevent the problem by removing the extra slash from UNC paths
specified for the scene file pathname.
You should try the maya "-amt" flag (Abort on Missing Textures)
to have maya fail when texture maps are not found. You can specify
this flag at the "Maya Flags:" prompt under the 'Advanced Options'
of the 'submit-maya' and 'submit-maya6' scripts.
DEBUGGING PROCESS
-----------------
What follows is the relevant excerpt from emails with the customer
used to determine the cause of the problem:
|
Debugging Session for Maya UNC Hanging Problem
|
(dp) However when I try rendering some more complex scenes (i.e lots of external textures)
(dp) (with "//" in the pathname) I get to the following stage..
(dp)
(dp) [root@Render07 scenes]# time maya -render -verbose 1 -proj //var/tmp/Maya -s 2 -e 2 \
-b 1 //var/tmp/Maya/scenes/ee064_010_v041_farm.ma
(dp) Maya (R), Version 5.0, 2003 04 01 00 02
(dp) Copyright 1997-2003 Alias|Wavefront, a division of Silicon Graphics Limited.
(dp) All rights reserved.
(dp)
(dp) .. and thats about it. I have left it in this state for over 12 hours
(dp) before giving up.
(ge) You mentioned AW asked if it happens when you use 'Render'
(ge) instead of 'maya -render'; does that make a difference in
(ge) this case?
(dp) Nope
(ge) Also, this might be a good time to whip out strace(1)
(ge) to see what the program is hanging on. With the render
(ge) hung, open another terminal to that machine and:
(ge)
(ge) 1) Use 'ps fax' to find the PID of the hung process.
(ge)
(ge) 2) Include the relevant part of that report here;
(ge) just the maya process hierarchy.
(dp) Appears to be running:
(dp) 1604 ? S 14:24 /usr/local/rush/bin/rushd
(dp) 2500 ? S 0:00 /usr/sbin/sshd
(dp) 29552 ? S 0:00 \_ /usr/sbin/sshd
(dp) 29553 pts/9 S 0:00 | \_ -bash
(dp) 481 ? S 0:00 \_ /usr/sbin/sshd
(dp) 482 pts/11 S 0:00 | \_ -bash
(dp) 527 pts/11 S 0:00 | \_ /bin/csh -f /usr/local/bin/maya -render -verbose..
(dp) 551 pts/11 R 4:26 | \_ /usr/aw/maya5.0/bin/maya.bin -render -verbos..
(ge) My guess is the lowest process in that hierarchy
(ge) is the one you want to focus on.
(ge)
(ge) 3) Use 'strace -p <pid_of_hung_process> to see
(ge) what it's hung on. Include (some of) that output
(ge) here.
(dp) Output from strace:
(dp)
(dp) access("//images/ee064_010_bg_v030.0698.iff", F_OK) = -1 ENOENT (No such file or directory)
(dp) Repeating....
(dp) access("//images/ee064_010_bg_v030.0698.iff", F_OK [unfinished ...]
(dp)
(dp) Looks like you're right. I'll look at the scene file to see if I can see
(dp) anything.
|
|
