Retospect 6.0.204 Mac OSX Tiger error "elem.c-821"

[Jonty]

I have received some slightly different error codes, but feel they are probably related to the same problem. I have received this error on running an incremental backup for the first time with 6.0.212:

Internal consistency check failed:

Assertion check at "tree.c-3444"

 

I then received this error after doing a recycle back-up of the same set: Internal consistency check failed:

Assertion check at "elem.c-816"

 

I have been using Retrospect for a long time and this is a back-up set which worked fine under all previous versions of Retorspect. I have a G5 DP 2.5 with 2GB Apple-supplied RAM, running Tiger.

 

I hope this post won't be deemed to be "not very helpful". I'd be happy to provide a debug log or debug code as referred to by CallMeDave if he could tell me what it is and where to find it.

[mjbolzan]

I have an update. I again reset my son's backup set to recycle. Last night, the backup went fine.

 

Could this mean there is something about a freshly converted system which causes problems? Perhaps spotlight indexing?

[sungoddt]

hmmmm, interesting, ok, i tried again, downloaded from scratch (third or fourth time), deleted/reinstalled (third time), this time my backup to a new backup set worked

 

so after several days of failing every time, it suddenly is "ok", but aside from emptying trash and deleting some video workfiles i haven't changed anything on the mac except for the multiple deletes/re-installs of retrospect

 

which leaves my confidence level at zero

 

backup software must be 100% reliable, not subject to unexplained success/failure

 

until dantz issues a fix or explains what external problem was/is causing these errors i obviously can't rely on retrospect

[mmsfo]

I've just updated two machines with Tiger : a 15" PB w/ 1GB memory and a G4 Quicksilver with 1 GB memory. I have also updated Retrospect with the 6.0.212 version for Tiger. Both computers are backed up by Retrospect to a Lacie d2 firewire external hard drive.

 

The PB update went perfectly and Retrospect backed up the system with no trouble.

 

By contrast, the G4 *seemed* to update Tiger perfectly but Retrospect started returning the "elem.c-821" error reported by others ... most of whom seem also to be running G4 towers. Perhaps this is a machine specific thing?

 

At any rate, I noted that Retrospect failed at precisely the same point every time : namely, somewhere in the middle of GarageBand help files. I ran all the usual checks on those files (permissions, verfiy, etc) with no change. Finally, I just trashed GarageBand from the hard disk and restarted Retrospect. It ran fine. My gut feeling is that something about the specific mix of hardware/files was causing something (table? counter? who knows?) in Retrospect to overflow and crash. At any rate, this report might be of help to others on this thread.

[CallMeDave]

Quote:

---

aside from emptying trash and deleting some video workfiles i haven't changed anything on the mac except for the multiple deletes/re-installs of retrospect

 

---

 

I hope you're not putting forth a theory that the replacement of the Retrospect application is what made this work... The only way to identify the cause of a software bug is to regress your test; go back to the configuration where it works/fails and see if it works/fails again.

 

If this is a software defect, the number of reports coming through the Forum are going to be noticed by Dantz (especially if a similar ratio of calls to their support line are being logged).

 

The best use of threads here on the Forum will be posts with _specific_ information about what works, what fails, and what was used each time.

[CallMeDave]

Quote:

---

Finally, I just trashed GarageBand from the hard disk and restarted Retrospect. It ran fine.

 

---

 

That's a shame.

 

It would have been an excellent opportunity to define the Garage Band folder as a subvolume and use it as a Source for some backup tests; if the error could have been isolated to a specific file or folder, that would be very helpful information.

[mmsfo]

For those interested, the offending folder was:

 

applications/GarageBand/Contents/Resources/en.lproj/GarageBandHelp/pgs/df1104.html.

[trustworthy]

I've gotten similar error messages. I no longer trust Retrospect. I hope Dantz decides to fix Retrospect because now it's broken. And I thought Dantz was the gold standard. I see no evidence of anything wrong my system. The problem is with the new version of Retrospect.

[CallMeDave]

Quote:

---

The problem is with the new version of Retrospect

 

---

 

Ya think?

 

Since Mac OS X 0.4 did _something_ that required Dantz to change Retrospect for compatibility, the idea that the new version was released with one or more defects is a bummer, but it's not earth-shattering.

 

It's Sunday night here on the West coast; let's at least wait until the start of the business week...

 

Dave

[sungoddt]

Quote:

---

 

I hope you're not putting forth a theory that the replacement of the Retrospect application is what made this work... The only way to identify the cause of a software bug is to regress your test; go back to the configuration where it works/fails and see if it works/fails again.

 

 

---

 

i'm not putting forth a theory, i'm making a statement of fact

 

there is sufficient evidence to suggest that the new release of retrospect is unreliable on some systems running tiger

 

on my system the other backup utilities i've tried are ok, all disk/filesystem checks pass, no other applications are crashing or giving weird results, only retrospect seems to have an issue

 

having finally managed one full backup out of 6-7 attempts certainly hasn't made me think the problem is resolved, enough people have had the same error that i want to know *why*, and as only dantz has access to the code generating the messages only dantz can do this

 

dantz doesn't give people support unless they pay

 

i'll happily offer dantz the same deal: if dantz pays me my standard day rates then i'm available to help track down the problem

 

dantz has my contact details, i await their purchase order

[Mayoff]

We have found some issues copying Spotlight files in Tiger that can cause an assert. Details can be found in the following article:

 

http://kb.dantz.com/article.asp?article=7976&p=2

[airnorth]

I have been having an interesting problem with performing a Retrospect backup lately and I thought it was tied to Flash. Here is the scenario:

 

Retrospect server which is an AGP G4, 1GHz, 1.5GB RAM, 2x100GB HDs on Apple bus, 2x250GB Western Digital HDs on a Sonnet PCI 133 card. OS is 10.4 and 10.3.9 (I have a version of each OS, 10.3.9 on one internal 100GB drive, 10.4 on the other) and Retrospect version 6.0.212.

 

Retrospect client is a G5 running OS X.4, latest firmware, 4GB RAM, 2x250 internal HD in RAID 0 stripe, client version of Retrospect is 6.0.110.

 

After upgrading to Tiger (format and clean installed – no upgrades or archive installs) the Retrospect software was updated. For the next week backups proceeded without problems, but then, two days ago, I started getting the following:

Trouble in Retrospect – Internal Consistency Check failed: Assertion check at “tree.c-3444”

 

I looked up the error in the Retrospect manual and tried the suggestions there. First, rebuilding the backup set catalog. Got the same failure at the same point in the backup. I then moved the Retro.config and Retro.icons files out of the Retrospect folder and into the trash, per instructions, and tried again. Same error. I made a note of the file where Retrospect was failing (00002912.html) and then went to the client and did a search for it.

 

On the G5, in /Users/Shared there is the following: /Library/Application Support/Macromedia/Flash MX 2004/en/Configuration/00002912.html Just for grins I deleted the /Users/Shared/Library directory and left the Finder window open. I launched Flash MX 2004 again and saw the Library and all subdirectories recreated. I deleted it again and re-ran Retrospect.

 

Retrospect ran completely, backing up all 47.2GB without errors. I've run Flash again since then and the directory is recreated, but this time different - it contains under Configuration /Help Panel/Dump. So, I am wondering if anyone else out there has had this problem yet? I’m also wondering why Flash is creating this directory in /Users/Shared and not in /Library or ~/Library? I don’t use Flash very often, so deleting that directory is no big deal for me but I would like to know if this is my problem or if anyone else has seen it? I checked both the Retrospect forums and Flash support sites and didn’t seen anything relevant. I’m guessing that this is something specific to my installation on the G5.

[CallMeDave]

Quote:

---

Just for grins I deleted the /Users/Shared/Library directory ... and re-ran Retrospect ... Retrospect ran completely, backing up all 47.2GB without errors.

 

---

 

Well, that proves it then. Retrospect crashed because of the presence of this directory.

 

Not.

 

If your test had included a regression, where you replace the directory and observe Retrospect crash again, you _might_ be able to suspect a cause. But the tree.c-3444 errors reported here on the Forum with Tiger were not consistant for the people reporting it, so it's as valid to claim that removing /Users/Shared/Library fixed your problem as it would be to claim that "multiple deletes/re-installs of retrospect" would change the program's behavior.

 

Did you read the Knowledge Base article reference in the post directly before yours? Dantz has identified Tiger components that do seem to cause a Retrospect crash for some users, some times. I'd suggest trying the steps that the software vendor suggests and see if that provides reliable operation.

 

Dave

[airnorth]

Dave,

 

The article you reference deals with Duplicating a drive, however I am doing a backup. That not withstanding, I'm not getting an assertion check error either - just the internal consistency check error. I only found it curious that if I delete the directory Flash creates on launch Retrospect will backup without errors. If I leave that directory, Retro will crash with the internal consistency check error. If I leave the Flash created directory, but run Disk Utility and let it repair the permissions and then run Retrospect, the backup will succeed; if I don't correct the permissions, the backup fails.

 

So they way I see it several things are happening. Flash is creating a directory in /Users/Shared that clearly Retrospect doesn't like and even Apple's Disk Utility identifies as having incorrect permissions set. There might be a problem with the Flash application, specifically the 7.2 update. If I run version 7.0 that directory never gets created and Retrospect marches on. Retrospect may be having problems in regard to the new features in Tiger - I know that there are outstanding issues and that the recently released update wasn't meant to be the final fix for all Tiger related issues.

 

On a personal note, I've been reading these forums for a while and I have a lot of respect for your knowledge of the application and I value your opinions and suggestions. However, in this form of communication tone is sometimes hard to distinguish and so I can't really tell if you are being sarcastic in your post or incredibly condescending.

[jfw25]

To add another observation of this assertion: I have several Macs at home; the Power Mac I use as a backup server is running Tiger, as is my laptop and one other desktop; another laptop and another desktop are running Panther. I have backup scripts set up to do incremental backups to hard disk files on the backup server once a week for each computer, on different nights.

 

The overnight backups of the clients running Mac OS X 10.4 are failing with the assertion at elem.c line 821, with the backup status window displaying "Updating catalog". As near as I can tell, the actual data retrieval from the clients succeeded. The crash appears to screw up the catalog, because immediately retrying the backup as an incremental backup crashed for some other inconsistency problem. A full backup (i.e. throwing away the backup set) worked. The backups of the 10.3 clients appear to work just fine. The backup server does not regularly back up itself (and typing that I can't believe how silly I've been :-), so I don't know whether it would succeed or fail.

 

The backup server is a MDD dual 1GHz with 1GB of memory and two 250GB firewire disks for backup space. The LAN is 100BaseT with an AirPort Extreme base station for the two laptops.

[CallMeDave]

Quote:

---

in this form of communication tone is sometimes hard to distinguish and so I can't really tell if you are being sarcastic in your post or incredibly condescending.

 

---

 

Back in the early days of internet sales, there was a Macintosh company who's mascot was a terrier named Jennifer, and her motto was "on the Internet, no one can tell you're a dog."

 

Since in real life I'm sweet as cherry pie, living online gives me an opportunity to be blunt, even if it's to the point of conflict. My final goal is to find answers, but I can't do that without having all the relevant information. Readers of my posts know that the majority of my contribution is soliciting information from those experiencing unexpected or undesired issues.

 

A post that claims "Retrospect crashed. I removed a file, and Retrospect didn't crash again. Therefore, the presence of the file was causing the crash" is a logical fallacy. A classic "not."

 

However, if the poster makes it clear that the program can be made to crash each time the file is present, and will work without crashing each time the file is removed, well, then it's getting somewhere. That's the distinction I was trying to draw from the original post, which did _not_ include any suggestion that the program crashed again when the suspected directory was recreated.

 

That being said, Retrospect shouldn't have any problem with permissions. Since it's running as a root process, it has read/write access to every file and directory on a drive, including esoteric permission matrices and Macintosh-only file flags.

 

>The article you reference deals with Duplicating a drive, however I am doing a backup.

Quote from KB#7976:

"During Duplication or Backup operations, you may see an error message like the following"

 

>I'm not getting an assertion check error either - just the internal consistency check error

"Internal Consistency Check failed: Assertion check at “tree.c-3444”" is indeed an assertion check error (or just an "assert" in programmer's slang).

 

>Flash is creating a directory in /Users/Shared that clearly Retrospect doesn't like and even

>Apple's Disk Utility identifies as having incorrect permissions set.

 

I have yet to read about a reproducible observance of Retrospect "not liking" the directory. The most current post claims "If I leave that directory, Retro will crash with the internal consistency check error," but only the most casual implications that other tests were performed that resulted in crashes.

 

Disk Utility's "Repair Permissions" is uninterested in files unless they were installed as part of OSX, or they are referenced by a .bom (Bill of Materials) file inside a receipt package in /Library/Receipts.

 

If, in fact, changing the permissions on a file or directory is changing how Retrospect behaves (from "crash" to "not-crash" _and back again_) then perhaps it's something similar to the Spotlight issue. Perhaps one set of permissions closes the file off from the system, allowing Retrospect to access it correctly, while another permission set results in the file being open the way the Spotlight files are. If a test can be constructed, with steps that can be reproduced by others, then the interaction can be proven.

 

Don't let my apparent condescension keep you from being interested in the solution to this. Just as with the RAID issue that was fleshed out here on the Forum a few weeks ago ("Interface slow" thread) it sometimes takes multiple community members to figure out what's going on. And in that case, as in now, I'm working only with the text posted by others. I have no RAID volumes, and I'm not running Tiger and Retrospect on the same machine.

 

Dave

[bjryan]

Oh What a wicked web we weave when we practice to deceive! hey Dave.

 

MayOff suggestion re spotlight fixed my incomplete backup probs, now have un interrupted backups

Thanks.

[sungoddt]

hmmmm, after a week or so of successful backups, retrospect has reverted to failing with the elem.c821 error as it did when first installed, the apparent trigger was installing adobe creative suite 2 (backup succeeded immediately before this, failed immediately after, and 8 hours later still fails)

 

 

 

dantz have tech notes/postings acknowledging that there is a problem with retrospect and offering possible workarounds, such as excluding spotlight files, and starting/logging-in in safe mode

 

 

 

i've tried both of these but still get the elem.c821 error, so still looking for a real resolution

 

 

 

when retrospect aborts and shuts down, if i restart it and do a recycle backup then it will just fail again at exactly the same point, however restarting it and doing a normal (incremental) backup on the partial backup set from the failure results in a 'successful' backup

 

 

 

i haven't had time to run a verify yet, this is burning a lot of time, any guesses about whether this backup set is safe to rely on?