davidduff Posted November 12, 2012 Report Share Posted November 12, 2012 i'm seeing assertion failures from retrospect engine. oddly, they are happening at 5 minute intervals. they seem to be related to an instability i observed with client communications (reported under a separate thread). "Assertion failure at "grx.cpp-1089", on threadID <hexID>" Quote Link to comment Share on other sites More sharing options...
davidduff Posted November 12, 2012 Author Report Share Posted November 12, 2012 it appears to me that my retroengine process is dying each time the above message is written to the logs. i didn't realize it at first, because one of the running activities (a groom operation) seems to survive the engine crashes. so this is a more serious problem than i originally thought. Quote Link to comment Share on other sites More sharing options...
Mayoff Posted November 12, 2012 Report Share Posted November 12, 2012 The GRX assert is caused by a catalog file that is corrupt due to a prior failed grooming operation. If you perform a catalog rebuild on the bad catalog file, the crash will no longer happen. Quote Link to comment Share on other sites More sharing options...
davidduff Posted November 12, 2012 Author Report Share Posted November 12, 2012 ok - thanks. i eventually reached that conclusion myself "the hard way" - i.e., everything else i tried failed badly. fyi, i tried doing a repair on the media set a couple of times and it crashed the engine and the console. not good. also, for my own understanding, in the case where a catalog is corrupt, shouldn't repair do essentially the same as rebuild? if not, why not? and why should repair crash both engine and console? Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.