Jump to content
bljohns

What causes "Assertion check at "elem16.c-687"???

Recommended Posts

I don't know what triggers this error, but I do know what the solution is.

 

Macintosh Retrospect will crash and fail to back up my two Windows network clients with the above error in a dialog box that only offers a "quit" button.

 

The solution is to "forget" the two network clients and then re-log into the clients and the reestablish the backup source drives in the backup script.

 

But why does this keep happening? What is causing this failure?

 

Also, possibly related....if I let Retrospect launch itself to make my weekly backups, I often find TWO instances of Retrospect running on my Mac and both of them trying to back up the same things to the same backup file, which always causes one of the instances of Retrospect running to error. If I launch Retrospect manually prior to backup time, everything seems to work fine. What can I do to fix it?

 

The log below shows both the "Assertion check" problem and then my solution at the bottom which always fixes the error.

 

 

 

? Retrospect version 6.1.126

launched at 3/17/2007 1:51 AM

+ Retrospect Driver Update, version 6.1.7.101

Internal consistency check failed:

Assertion check at "elem16.c-687"

Quit at 3/17/2007 1:52 AM

 

 

? Retrospect version 6.1.126

launched at 3/17/2007 1:52 AM

+ Retrospect Driver Update, version 6.1.7.101

Internal consistency check failed:

Assertion check at "elem16.c-687"

Quit at 3/17/2007 1:52 AM

 

 

? Retrospect version 6.1.126

launched at 3/17/2007 1:52 AM

+ Retrospect Driver Update, version 6.1.7.101

* WINDOWS1: forgotten from backup client database

* WINDOWS2: forgotten from backup client database

* WINDOWS1: logged into backup client database

* WINDOWS2: logged into backup client database

Share this post


Link to post
Share on other sites

This same thing is happening to me. It happened yesterday and again today with one client.

 

Anyone know of a way to stop this??

 

thanks!

Scott

Share this post


Link to post
Share on other sites

Quote:

This same thing is happening to me

 


 

Exactly the same thing?

 

- What version of the Windows client software are you using? On what version of Windows?

(the original poster does not say)

 

- What model of Macintosh are you using?

(the original poster does not say)

 

- What Type of Backup Set are you using? What make/model of Device are you backing up to?

(the original poster does not say)

Share this post


Link to post
Share on other sites

Quote:

But why does this keep happening? What is causing this failure?

 


A bug in the program.

 

Quote:

Also, possibly related....if I let Retrospect launch itself to make my weekly backups, I often find TWO instances of Retrospect running on my Mac and both of them trying to back up the same things to the same backup file, which always causes one of the instances of Retrospect running to error. If I launch Retrospect manually prior to backup time, everything seems to work fine.

 


I believe that this problem (two copies of Retrospect running) is unrelated to the Assertion Check issue.

Perhaps you have a test case that might help the Retrospect programmers fix this elusive bug (two copies running) that has been around for at least a couple of years. They may have tried to fix it, and it is not as common as it once was. I've seen it only once or twice. Here are some threads in these forums discussing this and indicating information that might be helpful:

Two Copies of Retrospect Running (2005)

Two Copies of Retrospect Running (2006)

 

Quote:

What can I do to fix it?

 


Nothing, but perhaps you can provide the Retrospect programmers (those that are left) with the information needed so that they can work to fix it.

 

Russ

Share this post


Link to post
Share on other sites

 

Sorry about the lack of information..I should know better.

 

I'm running Retrospect 6.1.126 on a new Mac Pro running MacOS 10.4.9. (I had the same issue on my Sawtooth G4)

 

This happens with Linux and Windows clients. I'm running client 7.0.110 on Linux and 7.0.112 on windows.

 

I get the same elem16.c-687 assertion failure.

 

I do not have two copies of Retrospect running.

 

I'm backing up to File on an external Seagate Firewire drive.

 

I have a client that is in this state now. I can reproduce easily by going to Configure->Clients, click "Configure..." for this client, then click on the Configure tab in the "Client Configuration" window. As soon as I click the Configure tab I get this assertion.

 

If I remove the client and add it back, it will work for awhile, but will eventually get back to the same state. (it would not be that big of a deal if I did not have to go back and re-create all of my sub volumes)

 

Let me know if I can provide any more info. I'll keep this client in this state for now...

 

thanks!

Share this post


Link to post
Share on other sites

Quote:

 

- What version of the Windows client software are you using? On what version of Windows?

(the original poster does not say)

 


 

I'm the original poster. Here is the information I failed to provide:

Windows client software: 6.5.136

Windows XP, fully updated

 

Quote:

 

- What model of Macintosh are you using?

(the original poster does not say)

 


 

Mac OSX 10.4.9

Machine Name: Power Mac G4 (AGP graphics)

Machine Model: PowerMac3,1

CPU Type: PowerPC G4 (3.3)

Number Of CPUs: 1

CPU Speed: 1.3 GHz

L2 Cache (per CPU): 256 KB

L3 Cache (per CPU): 2 MB

Memory: 1.25 GB

Bus Speed: 100 MHz

Boot ROM Version: 4.2.8f1

 

This is a "Sawtooth" G4 upgraded with a Giga Designs G4 1.3 GHz Processor

 

 

Quote:

 

- What Type of Backup Set are you using? What make/model of Device are you backing up to?

(the original poster does not say)

 


 

Backup Set: File

Device information (an external Firewire hard drive )

OXFORD IDE Device:

Manufacturer: Oxford Semiconductor Ltd.

Model: 0x1

GUID: 0x30E00100003326

Maximum Speed: Up to 400 Mb/sec

Connection Speed: Up to 400 Mb/sec

Sub-units:

OXFORD IDE Device Unit:

Unit Software Version: 0x10483

Unit Spec ID: 0x609E

Firmware Revision: 0x38

Product Revision Level: YAR4

Sub-units:

OXFORD IDE Device SBP-LUN:

Capacity: 233.76 GB

Removable Media: Yes

BSD Name: disk2

OS9 Drivers: Yes

S.M.A.R.T. status: Not Supported

Volumes:

BackFire II:

Capacity: 233.64 GB

Available: 13.47 GB

Writable: Yes

File System: Journaled HFS+

BSD Name: disk2s10

Mount Point: /Volumes/BackFire II

 

Is there any other information you can think of that I need to report? rolleyes3grem1.gif

 

--Brian

Share this post


Link to post
Share on other sites

Quote:

This is a "Sawtooth" G4 upgraded with a Giga Designs G4 1.3 GHz Processor

 


This is an unsupported configuration, and may be contributing to the problem.

 

Russ

Share this post


Link to post
Share on other sites

Quote:

Macintosh Retrospect will crash and fail to back up my two Windows network clients with the above error in a dialog box that only offers a "quit" button.

 


 

Does the assert occur at the same place that the second poster reported?:

 

I can reproduce easily by going to Configure->Clients, click "Configure..." for this client, then click on the Configure tab in the "Client Configuration" window. As soon as I click the Configure tab I get this assertion.

Share this post


Link to post
Share on other sites

Quote:

Quote:

This is a "Sawtooth" G4 upgraded with a Giga Designs G4 1.3 GHz Processor

 


This is an unsupported configuration, and may be contributing to the problem.

 

Russ

 


 

Russ, that's interesting. The Giga Designs processor is advertised as being "100% compatible". I have had no other issues with my computer because of the upgraded processor (that I'm aware of). Please point me to a Dantz/emcinsignia document that indicates what the supported configurations are.

 

I notice that some others with similar problems are all targeting an external firewire drive. Is that a clue?

 

One of the previous posters indicated his was a Sawtooth G4 also, but he didn't indicate it had been upgraded. Is the "Sawtooth" computer an "unsupported configuration"??

 

--Brian

Share this post


Link to post
Share on other sites

Quote:

Does the assert occur at the same place that the second poster reported?

 


 

Yes. My backups run at 3:00 AM Saturday mornings. In preparation on Friday nights I manually launch Retrospect (to make sure RetroRun doesn't launch two copies) and then I manually go to Configure and make sure both Windows clients have been "awakened" and do not appear gray in Retrospect's window. That seems to work...until one day I do the same thing as before and suddenly get the assertion error. Seems like it almost always happens after a backup session where I forgot to manually launch Retrospect (and RetroRun launched it), but I can't verify that 100%.

 

Last night I deleted the RetroRun folder in Library/Prefs, rebooted, relaunched Retrospect and set one of the Windows client backup scripts to activate in about 5 minutes. I quit Retrospect, and when the time came, RetroRun launched Retrospect, just one instance (yay!), and seemed to back up without incident. I'm hoping (in my case) maybe the problem was something wrong in the prefs file, but others have said this seems to be only a temporary fix. We'll see what happens in the near future and if I can capture more information I'll post it here.

 

--Brian

Share this post


Link to post
Share on other sites

I didn't say it was a problem, just that it was an unsupported Retrospect configuration. Can't put my finger on the place at the moment where it's said that upgrade cards are in the category of good luck if it works, but I believe that I saw such a document at one time.

 

It would be interesting to know if the problem can be repeated on the baseline Sawtooth G4 without the upgrade. If it can be repeated in that configuration, then you have eliminated the processor card as an issue. That's all I meant to say.

 

As to the external firewire issues, Dave (CallMeDave) would be able to help you better there. I've only done tape backups, never a disk backup, since 1992. I do know that there are some versions of some Mac models that have buggy Firewire controller chips, and there are some external drives that have buggy Firewire controller chips.

 

The Sawtooth G4 is a supported configuration as far as I know. I don't have one.

 

Russ

Share this post


Link to post
Share on other sites

Quote:

Last night I deleted the RetroRun folder in Library/Prefs, rebooted, relaunched Retrospect and set one of the Windows client backup scripts to activate in about 5 minutes. I quit Retrospect, and when the time came, RetroRun launched Retrospect, just one instance (yay!), and seemed to back up without incident.

 


You may have had some corruption in the RetroRun folder. That's an annoying bug that hits us about once a month or so and causes Retrospect autolaunch to fail. As for the "two copies of Retrospect running" bug, I've seen it once in two years or so. Wish I had gathered more data at the time.

 

Russ

Share this post


Link to post
Share on other sites

If the program asserts simply by visiting Configure->Clients->YourClient->Configure(button)->Configure(tab) then it has nothing to do with your Backup Set type.

 

The term "unsupported" means, in this context, that Dantz/EMC Dantz/EMCInsignia never tested Retrospect with any hardware other then stock models from Apple. Upgrade cards might work, they might not, but they're not qualified by the software publisher whos product you're using.

 

Since there are reports on this thread of the same assert on Windows clients 6.5.x and 7.x, as well as Linux client, it's reasonable to surmise that it's a Retrospect (Macinsosh) issue, in how it's communicating (or attempting to communicate) with clients.

 

When the program gives an assertion error, it also writes a log to your /Preferences/Library/Retrospect/ folder. I'm going to have to suggest that you open a support incident with EMC and send that log to them. Do it while you can...!

 

Dave

Share this post


Link to post
Share on other sites

This problem still exists in 2008 - apparently

I get Assertion check at "elem16.c-687" fails and backups do not complete.

 

Backup machine is G5 iMac with fully patched OS 10.4.11 running Retrospect 6.1.126.

Client is Lenovo (Pentium M) XP Pro 5.1.2600 SP2 bld 2600 - fully patched- retrospect client 7.0.112

Symantec client security firewall on xp mach configured to allow backups - worked before.

Daily Network backups over wireless (Airport G) fail consistently after having worked OK for only a month or so.

Attempts to repair catalogue result in no files being changed. Starting a rebuild of catalogue results in dialogue saying catalogue portion appears to be valid - then want to know if I want to rebuild anyway. Rebuilding catalogue takes a really long time; reading at 5 MB /sec over Firewire is pitiful performance - maybe it's the encryption. f you don't need the history, then you might as well make a new backup, it seems - that also takes a long time.

 

Don't know yet if rebuilding is going to help - still waiting!

Share this post


Link to post
Share on other sites

Hosed again -

rebuilding catalogue file does not help

 

Get

Trouble in Retrospect

Internal consistency check failed:

Assertion check at "elem16.c-687"

 

same as before. Any ideas?

Share this post


Link to post
Share on other sites

Quote:

This problem still exists in 2008 - apparently

I get Assertion check at "elem16.c-687" fails and backups do not complete.

 

Backup machine is G5 iMac with fully patched OS 10.4.11 running Retrospect 6.1.126.

 


Um, and how do you expect things to change in 2008 if you are running an outdated copy of Retrospect? The bits don't just magically change. Current version is 6.1.138. Updates are here:

http://www.emcinsignia.com/supportupdates/updates/#UPDATETYPE8

 

You also don't indicate what version of Retrospect Driver Update ("RDU") you are running. RDU version history is here, with links to downloadable copies of each version:

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

Share this post


Link to post
Share on other sites

Quote:

rebuilding catalogue file does not help

 


 

There are multiple posters in this thread, and one of them reported that:

 

I can reproduce easily by going to Configure->Clients, click "Configure..." for this client, then click on the Configure tab in the "Client Configuration" window. As soon as I click the Configure tab I get this assertion

 

In response to that report, I noted that such a situation would indicate that the Backup Set itself (and thus that set's Catalog) would have nothing to do with the issue (whatever it might be).

 

> Get

> Trouble in Retrospect

> same as before

 

Doesn't tell us _when_ the error happens. Does it reproduce using the same steps that were reported above?

 

The fact that the configuration had worked before suggests that the actual programming files are compatible, which would lead to troubleshooting the ever-changing preferences file.

 

What happens if you use a backup copy of your preferences file from when the configuration worked, or, in the absence of having a backup of this valuable file, moving or renaming your existing preference file and allowing Retrospect to create a new one for testing?

 

Dave

Share this post


Link to post
Share on other sites

Greetings Dave - thanks for responses.

1. Retrospect update 6.1.138 has been found. Thanks for the heads up. Note Mac v 6.1 does not support automatic updates (unlike Windows version - although I haven't gotten it to actually work - work place firewall issues, I think). I guess I need to check into getting to alert me when Mac version updates are available.

2. Apparently bits do change by themselves, especially when they are in preference files - I saw the post you mention and several other that suggest replacing the Retrospect preference file - including the very first one in this thread (effectively). Question is - if this is the problem, why is the preference file getting messed up?

3. The Retrospect version info (complete - for when this problem presented) is vers. 6.1.126, device access vers. 1.0.107, driver update ver. 6.1.9.102.

4. My error comes up when I try to run a backup of a Windows client. That's why I mentioned that the backups fail.

 

If I get any more info, I'll post it.

 

Best regards.

Share this post


Link to post
Share on other sites

More information on the "Assertion check at "elem16.c-687" failure error:

 

1. After updating the Retrospect software to the current v. 6.1.138 (and also the client application on the WIndows computer to v. 7.5.116 - which was on the .dmg along with the update), the error and failure to back up still presented itself upon trying to back up a Windows XP client computer over the wirelesss network.

2. The same error also came up when "visiting Configure->Clients->YourClient->Configure(button)->Configure(tab)" as noted in earlier posts.

3. The error was avoided by using the work around put up by the original poster (four years ago!), which is to "forget" the client and then reconnect. After that I had to respecify the source drive on the client computer before the backup would run. All this still allowed using the current back up set.

4. The root\Library\Preferences\Retrospect\Retro.Config (6.0) file modification date was updated after the now successful incremental backup completed.

 

So the upshot is that the Retrospect version, current as recently as December 2006 (according to its post date on the Retrospect update page), had not resolved my getting this error, which was reported back in 2003. That appears to be supported in earlier posts in March 2007 by rhwalker, who also kindly responded to my earlier post. All the behaviour I see matches earlier posts. All this does not suggest much about whether the new version has fixed the error so it does not come up again- but time will tell.

 

One other question does come up - why does the Retrospect 6.138.1 update for Macintosh include the Windows client 7.5.116 (the same version number as is listed under clients for the Windows Retrospect Professional application) when the Retrospect update page Macintosh offerings still only lists separately the Client version 7.0.112? Doesn't make a whole lot of sense.

Share this post


Link to post
Share on other sites

Since my original post I've changed to an Intel-based MacPro 2x3 GHz Dual-Core Intel Xeon with 2 GB 66 MHz DDR2 FB-DIMM for memory. I did not migrate anything from my old G4 PowerMac, but instead chose to do a fresh install of everything, including Retrospect.

 

I've not seen the "Assertion check at "elem16.c-687" error since changing to the new Mac, but I live in fear of the day. It seems once this starts happening, it will continue to pop up seemingly without rhyme nor reason, which makes the whole backup scheme unreliable and disappointing.

 

Sadly I'm still seeing instances of Retrospect launching itself twice when it auto-launches to do my backups on Friday evening/Saturday mornings. Of course the 2nd instance of Retrospect fails when it tries to back up because the first instance has the backup sets busy. I try to remember to launch Retrospect on Friday evenings before I go to bed to avoid the problem. I've also set up a CRON job with Cronnix to launch Retrospect about an hour before the auto-backup schedule just in case I forget. That's solved the dual-launch problem.

 

I continue to use Retrospect because of my investment in the software and because of a (probably now-misplaced) sense of loyalty from the days when I used DiskFit on my old Mac Plus. Retrospect has rested on buggy laurels for too long and seems to be software that's becoming increasingly irrelevant with the advent of such utilities as Time Machine, Time Capsule, SuperDuper, etc. It's sad to see such a great product go stagnant.

 

--Brian

Share this post


Link to post
Share on other sites

> The root\Library\Preferences\Retrospect\Retro.Config (6.0) file modification date was updated...

 

Actually it's /Library/Preferences/Retrospect/Retro.Config (6.0)

 

> Retrospect has rested on buggy laurels for too long and seems to be software that's becoming

> increasingly irrelevant with the advent of such utilities as Time Machine, Time Capsule, SuperDuper, etc.

 

While there is no doubt that Retrospect's code is desperately in need of modernization, the fact is that the programs you mention simply do not provide the capabilities that Retrospect does. Sure, SuperDuper! and CCC are excellent cloning applications, which use native unix commands for their file writing. And TimeMachine is easy to use (when it works) and is integrated with Apple's system installer DVDs for easy bare metal restores.

 

But if you want to maintain multiple incremental backups of user defined data sources, or backup to high capacity tapes, or manage data for multiple machines on a network, or match identical files to maximize storage space, or maintain a searchable catalog of backed up files without needing access to the actual storage media, or be able to restore files based on complex attribute criteria, etc etc etc, other technologies won't do it for you.

 

I find those features relevant still today, just as they were back when DiskFit became Retrospect.

 

Dave

Share this post


Link to post
Share on other sites

Dave:

 

Sorry, it was my frustration speaking. No doubt about it Retrospect is a very capable package with lots of mature features. I'm frustrated at the lack of any helpful solution to the two problems mentioned in this thread -- the dual-launch and the Assertion error when backing up remote clients. I guess the dual-launch is easy enough to work-around and it doesn't cause data loss, but if that irksome Assertion error shows up again for me on my new Mac then the **reliability** of the backup scheme is totally shot. On my old Mac, even after I solved the error by "forgetting" the PC clients and adding them again, I never knew when the error would pop up again and stop a backup. And you can bet Murphy will see to it that if the error does pop up for me again, it will be THAT failed backup session that will be the one when I needed the backup to have worked as it was designed to do.

 

So I guess my frustration is not so much with the product, but with the lack of support from the company that bought the company that wrote the product.

 

--Brian

Share this post


Link to post
Share on other sites

Quote:

...I solved the error by "forgetting" the PC clients and adding them again,...

 


 

Another method was suggested, but apparently not tried. It would be interesting to know if a fresh copy of the preference file would or would not solve the problem.

 

 

Dave

Share this post


Link to post
Share on other sites

Heya,

 

Just started having this problem today. When I launch a backup I almost immediately get the elem16.c-687 message and the backup ends. I can also create the error by going to the "Backup Client Database" tab, selecting the first system that would normally get backed up, then selecting "Configure". (That is, Configure->Clients->(client name)->Configure).

 

Suspecting that dropping/adding the first client would fix the situation (it always has in the past), I made a tarball backup of /Library/Preferences/Retrospect. I then dropped/added the first client and now backups are working again.

 

Assuming I get permission, I'm happy to provide the before/after copies of the Retrospect Preferences directory and all my system configuration details to someone at Dantz.

Share this post


Link to post
Share on other sites
I'm happy to provide the before/after copies of the Retrospect Preferences directory and all my system configuration details to someone at Dantz.

 

 

That's gonna be a challenge, as Dantz Development Inc. no longer exists!

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×