Jump to content

Assertion check elem.c-821


Recommended Posts

  • Replies 102
  • Created
  • Last Reply

Hi rickb

 

The errors occur during the matching phase right?

Can you remove only the Adaptec SCSI adapter from the machine and start a backup?

 

I know this is similar to what we have tried before but I still think SCSI communication could be partially to blame for this.

 

Thanks

Nate

Link to comment
Share on other sites

hi natew...

 

ok, i reeeeally didn't want to pull the adaptec card but I have.

I waited until error was occuring and pulled the card...

On retry, I haven't encountered the error where I expected to. So you may have been correct.

I'll give it a few more runs before I'm convinced but thanks for your persistence in tracking this down.

 

In any case, many thanks.

 

...rick

Link to comment
Share on other sites

  • 2 weeks later...
  • 3 weeks later...

Hi

 

I wonder if some file names stored in the backup set are causing problems. That could explain why it happens during matching. If you turn off the matching option and use the documents selector to limit what is backed up does the error still occur?

 

How long does it take after a recycle backup for the error to occur again? Does the error tend to occur after the backup of a particular client has completed?

 

Thanks

Nate

Link to comment
Share on other sites

natew, the problem is intermittent, and seems to be related to the number of files. The only filtering being done is that the "all files except cache files" option is selected. When the error occurs, I never get to see what the number of files being matched is so I cannot tell if there is some common factor. The error has, repeat has, occured during 'recycle' backups.

 

When the error occurs, if I just rerun Retrospect then the error usually recurs. If I restart the effected machine or files on the effected machine are 'touched' then the error doesn't seem to recur. If I were to guess I would suspect a problem with 'hashing'. The absolute number of files being matched doesn't seem to be the problem because I have had large backups run just fine.

 

The intermittent nature (maybe 25% of runs) means that gathering data takes a long time. Do you have access to an instrumented version of Retrospect available that I could run for awhile and see if we can accumulate some useful logs? I am willing to run a 'beta' version if that will help.

...rick

Link to comment
Share on other sites

Hello, all!

 

I am new to this thread, but not to this problem.

 

 

 

Internal consistency check failed: Assertion check at "elem.c-821"

 

 

 

Getting this error on Automated Backups every night, and occasionally on manual backups of the same script. System is as follows:

 

 

 

G4 466MHz Graphite with 384MB RAM

 

OS X 10.2.4 (Still on Jaguar due to Share Permission issues still present in Panther)

 

LaCie External AIT FireWire Drive connected to native FireWire on the G4

 

Retrospect Workgroup 6.0.193, Retrospect 6.0 Driver Update 5.4.104

 

 

 

No SCSI in this Mac.

 

 

 

The script backs up first a secondary ATA drive, then the boot ATA drive. The backup always gets all the way thru the secondary drive, and always gives the elem.c-821 error on the boot drive. Ran Permission Fix, Disk Warrior, Norton on the boot drive with minor date & time errors, always repairable. Still get the elem.c-821 error everytime.

 

 

 

Here's the log from last night:

 

 

 

? Retrospect version 6.0.193

 

automatically launched at 6/7/2004 10:00 PM

 

+ Retrospect Driver Update, version 5.4.104

 

 

 

+ Normal backup using EM2-2004 at 6/7/2004 10:00 PM

 

To backup set EM2-2004…

 

 

 

- 6/7/2004 10:00:28 PM: Copying Bringing Me Down…

 

6/7/2004 10:11:31 PM: Comparing Bringing Me Down…

 

File “Internet Mail Server mail log”: different data size (set: 87,119, vol: 87,565), path: “Bringing Me Down/Servers/EIMS Server 3.2.3/Internet Mail Server mail log”.

 

File “Incoming Mail 1”: different modification date/time (set: 6/7/2004 9:41:01 PM, vol: 6/7/2004 10:10:01 PM), path: “Bringing Me Down/Servers/EIMS Server 3.2.3/Mail Folder/Incoming Mail 1”.

 

File “Incoming Mail 6”: different modification date/time (set: 6/7/2004 9:15:31 PM, vol: 6/7/2004 10:11:31 PM), path: “Bringing Me Down/Servers/EIMS Server 3.2.3/Mail Folder/Incoming Mail 6”.

 

File “Incoming Mail 7”: different modification date/time (set: 6/7/2004 9:43:01 PM, vol: 6/7/2004 10:12:01 PM), path: “Bringing Me Down/Servers/EIMS Server 3.2.3/Mail Folder/Incoming Mail 7”.

 

File “Accounts database”: different modification date/time (set: 6/7/2004 10:09:37 PM, vol: 6/7/2004 10:13:13 PM), path: “Bringing Me Down/Servers/EIMS Server 3.2.3/Mail Folder/em2design.com/Accounts database”.

 

File “Inbox”: different data size (set: 1845, vol: 24), path: “Bringing Me Down/Servers/EIMS Server 3.2.3/Mail Folder/em2design.com/tmykytka/Inbox”.

 

6/7/2004 10:14:55 PM: 6 execution errors.

 

Completed: 50 files, 1.4 GB

 

Performance: 338.7 MB/minute (269.8 copy, 455.0 compare)

 

Duration: 00:14:27 (00:06:10 idle/loading/preparing)

 

 

 

- 6/7/2004 10:14:57 PM: Copying TheMan…

 

Internal consistency check failed:

 

Assertion check at "elem.c-821"

 

6/7/2004 10:14:57 PM: Execution incomplete.

 

 

 

6/8/2004 8:55:32 AM: Execution incomplete.

 

Total performance: 0.1 MB/minute

 

Total duration: 00:14:29 (10:46:44 idle/loading/preparing)

 

Quit at 6/8/2004 8:56 AM

 

 

 

 

 

 

 

This occured with several earlier rev's of Retrospect, including 5.0.x versions.

 

 

 

I have the "Always Require Authentication" 'ON'. Trying it tonight with it 'OFF' to test.

 

 

 

Tried duplicating script, complete reset of script and storageset, re-installation of Retrospect (full Pref's trash too). Nothing has changed. Still getting the Internal consistency check failed: Assertion check at "elem.c-821".

 

 

 

Dantz, please assist us all in this thread with this issue! Is there a Beta version to try... Or a version with special logging to possibly see where the script is hanging up at?

 

 

 

Thanks,

 

Scott K.

 

Tweek Digital

Link to comment
Share on other sites

Quote:

Here's the log from last night:

 


 

The operations log isn't going to help here. What you need is the assertion check log that you'll find in your Retrospect preferences folder.

 

Unfortunatly, the shipping build of Retrospect does not have any of the debug code that would be helpful to Dantz. To track this down, you need for them to provide you with their special debug version of the program, which will generate a hinted version of the assert log, which can help to track the problem down.

 

I'd suggest that you call Dantz Tech Support. I'm pretty certain that upgrades from Retrospect 5.1 to 6.0 included a single support incident, so it may not cost you anything. And historicaly, users who have paid for support that turns out to be a Retrospect bug have been successful at requesting a refund of their support fee if they paid one.

 

Dave

Link to comment
Share on other sites

You're not reporting a bug. You're having an issue, the cause of which is unknown.

 

Before you can identify it as a defect in the software, you need to come up steps that will reproduce the issue on another clean system.

 

There are a lot of tests you could do to isolate when this happens foryou; for example, will it assert if you select only the boot drive? Will ilt assert if you select a defined subvolume on that drive?

 

That you get the error everytime will actually be helpful in isolating the problem.

 

But if you want someone to walk you through this, you're going to have to use a support incident with the staff at Dantz.

 

If it's an issue with your hardware/software, then tech support costs money.

 

If the issue turns out to be a defect in the software, you can request a refund.

 

These Forums are not offered as support by Dantz; they are offered as a way for users to help users, with some participation (and moderation) by some Dantz TS folks.

Link to comment
Share on other sites

  • 1 month later...

Hi, me again

 

I have now had this problem again pretty much after each night of running a backup server script. All of the clients have been macs (OS X) and have been preceeded by those FSMake Unicode errors (when file system logging is on). I don't get these errors on all OSX clients, but some clients have them and don't cause -821 errors.

 

My setup is a LaCie (SONY) AIT-2 connected to a real FireWire port (no 3rd party here) on a MDD G4 1GHz with 768MB of RAM, OS 10.2.8 and no other software running except the Event Handler w/ python emailing me twice a day.

 

This error has showed up on 2 different backup sets and even after a recycle. So, I am guessing that there is something wrong with the preference files as has been suggested earlier. I trashed them a while ago and that did grant me a few weeks of -821-free operation, but it forced me to find all the clients on the network again and make new scripts. I only have about 30 clients but that still takes me days to locate all the laptops and and other intermittently connected machines. So I am not happy to have to trash all my work regularly.

 

I have a few questions:

 

1: What in the preference files can possibly become "corrupt" while the server is running in such a way that the whole program has to be quit?

 

2: Why can't scripts, client lists and whatever becomes corrupt be kept in separate pref-files? This would, to me, make a lot more sense.

 

3: How can a so-called server just stop to wait for me to press quit? To me server means something running by itself, something stable, not to be affected by external problems (I am not getting into net retry errors here...) If only it could log the error and try to move on, or restart itself and try again. Just stopping, and not even having the event handler send out an error message seems kind of dumb.

 

Ideas anyone? I totally understand rickb, this is very frustrating, but I seem stuck with RS until I can get a PC server too and run 2 separate systems, with BRU for the Macs and something else for PC, so I would like this to work.

Link to comment
Share on other sites

An assertion checck error means the program has crashed, so if you didn't get the modal "OK" dialog box you'd get nothing at all. Neither one is going to be any better, so at least this way you get some visual clue that the program died.

 

Retrospect generates an error log for these assertion errors, located in /Library/Preferences/Retrospect/. However, I'm pretty sure that the log does not contain any helpful debug data unless you're running a debug build of the program. If you work with Dantz tech support they will provide you with such a build, and the resulting log can be kicked back to them for troubleshooting.

 

BTW, it is unlikely that the entries you see with file system logging enabled are "causing" the assertion check; such verbose entries are normal to see as the program goes through its routines to read files. The program will give an actual error (such as a -43, file not found) if the things it does don't work.

 

Dave

Link to comment
Share on other sites

Hi Dave,

 

So I guess what I would like is just a note of the crash and a restart, not a full stop. Well, I would really like a server that doesn't crash at all..

 

About the file system errors: Yes, I think they are minor too, I just noted that when they didn't occur there were no -821 errors either. Any ideas on why they occur? They all seem to mention Unicode. Is there still an issue with unicode in RS6? I thought that was supposed to be fixed?

 

I will call the Swedish agent for Dantz, as they claim to have support and have someone come here and look at the beast. If I get any help, I will be sure to relay it to you here.

 

/eric

Link to comment
Share on other sites

Add me to the list of those suffering from this problem. Here's my setup:

 

Retrospect Backup 6.0.193 for MacOS X

Driver update version 5.2.101 (will soon try latest which is 5.6.102)

MacOS X 10.3.4

PowerMac G5 dual 2 GHz, 1 GB RAM

LaCie d2 AIT2 tape drive connected via Firewire 400

 

I see the error in both recycle and incremental backups. Here's a recent log entry:

 

? Retrospect version 6.0.193

launched at 7/27/2004 7:02 PM

+ Retrospect Driver Update, version 5.2.101

 

+ Executing Immediate Backup at 7/27/2004 7:13 PM

To backup set Temp Doolin Backup…

7/27/2004 7:13:09 PM: Recycle backup: The backup set was reset

 

- 7/27/2004 7:13:09 PM: Copying Doolin…

7/27/2004 9:10:30 PM: Comparing Doolin…

Can't read file “superatm.db”, error -39 (unexpected end of file), path: “Doolin/Applications/Adobe Acrobat 6.0 Standard/Acrobat Distiller 6.0.app/Contents/MacOS/DistillerLib.shlb/Contents/MacOS/Data/superatm.db”.

Can't read file “SAMPLE2.PS”, error -39 (unexpected end of file), path: “Doolin/Applications/Adobe Acrobat 6.0 Standard/Extras/Customer Support/Test Files/SAMPLE2.PS”.

Internal consistency check failed:

Assertion check at "elem.c-821"

7/27/2004 9:25:58 PM: Execution incomplete.

Remaining: 320976 files, 39.9 GB

Completed: 4437 files, 375.5 MB

Performance: 317.6 MB/minute (352.5 copy, 26.7 compare)

Duration: 02:12:49 (00:02:01 idle/loading/preparing)

 

Quit at 7/27/2004 9:26 PM

 

I'm not sure if it's related but I started seeing these errors about two months ago, then I saw a general degradation in overall system and application stability (lots of application crashes with "bad kernal access" errors) culminating in several days of random kernal panics. The computer went in to the Apple repair center as they thought it was a CPU or RAM problem but of course the #%$^& thing didn't crash once while in the shop (they were using a separate user account, not my main account) and Apple Hardware Test showed no problems. So after several weeks of them saying they were going to fix it (logic board replacement etc.) they simply returned it to me saying they couldn't duplicate the problem. First thing I did when I got it home was attempt to run a full backup with Retrospect and I got the error above.

 

I guess I'll try the new driver and trashing the preferences and see if that helps...

 

Anxiously awaiting a solution...

 

Craig

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.


×
×
  • Create New...