Daniel Browne wrote:
> Unfortunately I've already overwritten the bad frame logs from today's test=
> s. On the off chance that it will be of use you'll find a successful frame =
> log at the end of this message.
I have plenty of those ;)
Need the text with the actual error to offer you a good regex
to search for.
You can see the usage of LogCheck() by doing a grep on all the submit
scripts for LogCheck, ie. 'grep LogCheck /path/to/your/rushscripts/*.pl'
The code for that function is defined in .common.pl, and can take
one or more regex's as an array, so that you can search for several
strings in one shot. It also has a separate string that resets the
search, useful for it to skip over retries.
> To me it looks as if AfterEffects is bound to the static location of the Ma=
> c's /Library as well as the intended install locations of some if not all o=
> f the other pieces of the CS5 suite itself, so it may not be possible at al=
> l to have a central library.
I don't suppose symbolic links would help? ie. make a symlink(s)
in the /Library/xxx directory where the extra fonts should go.
Might be worth a shot.
> Using killall on aerendercore or aerender so far has not solved the zombie =
> problem, so this issue may have gotten worse in CS5 from what you've descri=
> bed.
Since zombies aren't really processes, they're just the 'exit code'
of the process, you don't really have to worry about them too much
unless there's a lot of them.
Killing them is useless, because they're already dead,
just like in the movies ;)
Zombies are created when the parent doesn't reap the exit code,
which probably means the parent is still around somewhere.
> One aspect of MacOS X that frustrates people who've used other unix pl=
> atforms is that there are situations in which even kill -9 as root will not=
> terminate a stuck process.
This actually can happen on all unix platforms.. I used to run
into this constantly on SGI and linux in the 90's (and to date)
whenever a process is reading or writing to a hard mounted NFS share
where the server has gone down or is not responding.
The hanging process part is OK, you want it to do that, but if
root comes along with kill -9, it SHOULD die, but it often never
does. This is because the process is stuck in kernel mode, where
signals aren't processed immediately the way they are in user mode.
It can be done, but it's tricky/messy to do in kernel code at all
the points where a hang could happen, so often processes stuck in
kernel mode are unkillable.
That would go for any kernel or driver operation that is 'stuck'
for some reason, like tape operations or floppy drives...
other situations where I've seen this occur.
> This is particularly true if you have an OpenGL=
> or graphics driver error. You'd think having created OpenCL that Apple wou=
> ld finally want to do something about that...
It's all to do with the driver code and how well it's written
to handle pending signals. It's very tricky to properly detect
and unravel a kernel mode call that's got pending signals and
have it react like a user mode operation.
> In the mean time I'll give the LogCheck function a try.
Yes; see the usage in other submit scripts (like submit-maya,
submit-nuke and submit-lightwave), and the definition of the
function in .common.pl
--
Greg Ercolano, erco@(email surpressed)
Seriss Corporation
Rush Render Queue, http://seriss.com/rush/
Tel: (Tel# suppressed)
Fax: (Tel# suppressed)
Cel: (Tel# suppressed)
|