Jump to content

Assertion check elem.c-821


Recommended Posts

  • Replies 102
  • Created
  • Last Reply

Quote:

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.

 


 

Be sure.

 

Retrospect has often been regarded as the classic "canary in a coal mine." It taxes the file system of machines on which it runs, and has very often exposed hardware or software abnormalities for users.

 

The fact that you machine has had lots of kernal panics without Retrospect running makes it clear that you have a problem unrelated to this program. And in fact it _might_ be something Retrospect can help you isolate (when AppleCare would not).

 

Some things I'd suggest trying. I understand that you may very well not have the resources to do this stuff, but it's probably the only way to get the answers you're looking for.

 

- Update tape drive firmware as NateW suggests.

 

- Boot from an entirely different HD; an external FW drive, for example, with a fresh system install. Disconnect the internal HD from the bus, to isolate this between system software/system hardware.

 

- If Retrospect doesn't crash with a different drive, boot a different Macintosh with the original drive and test again; if it crashes a different Mac you've isolated it to the hard drive.

 

- If Retrospect crashes with the different drive, try removing/swapping/ memory cards.

 

Dave

Link to comment
Share on other sites

Time for a status update. Here's what I changed:

 

- Installed Retrospect Driver Update 5.6.102

- Removed all Retrospect preferences

- Reloaded backup sets and rebuilt all scripts from scratch

- Removed all non-essential items from USB bus (powered hub in my Sony monitor, etc.) and attached Apple keyboard and Apple mouse directly to the G5.

- Removed all non-essential items from Firewire bus including LaCie external 250 GB drive and LaCie d2 AIT2 tape drive.

 

With the above setup, I ran for about 4.5 hours doing code editing (BBEdit), web surfing (Safari), mounted external drives from a PowerBook and a Dell PC, and received/sent email via Eudora with no applicaiton or system crashes - only oddity was my "menulets" (menu bar clock, volume control, etc.) and my desktop background both disappeared for awhile but came back after a quick reboot.

 

I then shutdown, attached the LaCie tape drive, and started up again so my incremental backup could run. It copied fine (about 500 MB) but then crashed with the usual "Assertion check at "elem.c-821"" error right at the start of the compare operation. After quitting Retrospect, I tried to post to this forum twice but got the SPOD in Safari each time. I finally had to post from another machine.

 

Next step? Try the things Dave suggested - I'll keep you posted...

 

Craig

Link to comment
Share on other sites

  • 2 weeks later...

And time for yet another status update. Here's what I've tried lately:

 

- swapped out the 1GB memory with new Samsung memory -> still crashes

- swapped out the SATA hard drive with new one, reinstalled 10.3.4 & iTunes data -> still crashes

- saw assertion for "tree.c-3442" on one crash instead of usual elem.c-821

- also had one backup where it couldn't read one file (error -39, unexpected end of file) and couldn't save the catalog (error -108, not enough memory - yeah right!)

- took machine in for diagnostics by Apple Technician

-> he ran open firmware service diagnostics for several hours -> no hardware problems

-> he'll run for at least 48 hours more just in case

-> he put boot into "verbose" mode and reviewed logs

-> logs say that part of Retrospect is crashing at boot time

-> he suggests downgrading to MacOS 10.3.3 to see if problem still exists as he thinks there might be a compatibility issue between Retrospect (6.0.193) or the driver (5.6.102) and Mac OS 10.3.4

 

Anyone from Dantz want to comment on these findings?

Link to comment
Share on other sites

Quote:

logs say that part of Retrospect is crashing at boot time

 


 

Part of Retrospect? What is the exact log entry for this?

 

I'd suggest that you need to contact Dantz tech support directly, and open an incident that will get you personal attention.

 

Tech support can provide you with a debug version of Retrospect, that will generate an assert log with a "stack crawl" that might lead to an answer.

Link to comment
Share on other sites

  • 2 weeks later...

You can add me to the long list of people suffering from this error. We are running Retrospect for Mac OS-X version 6.0.193, along with the latest 5.6.102 updater file in the Retrospect application directory. It is running on a Mac OS-X server (v10.3.4). Recently our copy of Retrospect halts very shortly into the execution of any script with the following error message:

 

"Trouble in Retrospect. Internal Consistency Check Failed. Assertion check at 'elem.c-821'"

 

I have tried most of the fixes offered in this extensive thread

- Trashing Retrospect preferences

- Deleting backup sets/scripts and re-creating.

- Updating all client versions on remote computers to the latest versions (our clients are OS9, OS-X, Win XP, Win NT4- the works!)

- Updating the retrospect version on the server with the latest driver updaters

 

I have also tried innumerable permutations of the backup process to try and isolate potential causes, including

 

- Reinstalling the program

- Only backing up from local volumes instead of network clients (no change)

- Backing up to a local file rather than to our SCSI AIT tape drive (no change)

- Toggling options inside backup scripts such as "All Files" instead of "All Files Except Cache Files" (this made a temporary difference and I thought this may have done the trick, but the bug came back)

- Toggling the "data matching" options (no change)

- Doing an immediate backup, not a scripted one, and selecting (say) a single client (in which case the error comes up even when I click "Preview"- before I even get to the backup proper!)

 

I'm thoroughly sick and tired of Dantz's lack of support, and was incredulous when Dantz suggested I had to pay for support to fix what is very obviously a widespread bug in their program. If it wasn't for fellow users posting to this forum, as far as Dantz is concerned the problem does not even exist.

 

I would appreciate it if a Dantz support person could acknowledge what emerging picture is appearing for them regarding this bug and what the commonalities are for the problem- and when we can expect Retrospect 6.1 as a free upgrade to fix it!

Link to comment
Share on other sites

Hi

 

The most recent driver updates included fixes to resolve the assert errors that were happening due to problems in Retrospect.

 

Assert errors can happen for a number of reasons - not just problems in Retrospect. There may be a memory management or physical memory problem on your machine that is causing the problems.

 

If possible I would try the following to isolate the cause of the failure:

Install a clean OS and Retrospect + updates on a firewire drive, then boot from that drive and see if the problems persist. If the backups run smoothly we can assume the trouble is caused by something in the OS.

 

You could also try installing Retrospect on another machine to see if the problems continue there. That would help us rule out memory or I/O problems as the cause of the failure.

 

Thanks

Nate

Link to comment
Share on other sites

It really is a shame that the KB article that accompanies the 5.7.104 RDU

 

http://www.dantz.com/index.php3?SCREEN=kbase&ACTION=KBASE&id=28135

 

says nothing about fixes for issues other then the added device support listed.

 

Even just a little hint about "various bug fixes" would encourage users to load this update even if they don't have the devices listed.

 

Dave

Link to comment
Share on other sites

Hi Nate,

 

I might just add that I have tried a fresh install of 10.3 (I was upgrading from 10.2.x) on a different ATA drive (separate bus) and reinstalled retrospect (but moved my prefs over because I don't want to keep losing my scripts). Things were OK for 6 days, then the old 821 was back. The only thing I haven't tried is changing the RAM. So, that didn't help me much.

 

I will try the RDU of course. If that doesn't work I might have to consider the RAM.

 

I agree with Dave, new users probably won't load the RDUs if their devices are already supported. How about just having the application version number increase by 0.0.1? That would make it easier to keep track of current versions. Now we have the server, client and RDU versions to report when things go wrong. And things *do* go wrong. wink.gif

 

Heres hoping that this RDU will be the end of this thread...

 

/e

Link to comment
Share on other sites

So just which RDU is supposed to (undocumentedly) fix this bug? I note that 5.7.104 has just been released. Is it this one, or an earlier one? I agree with the previous post that said it's very poor of Dantz to omit this from the changelist. More information, please!

Link to comment
Share on other sites

Hi

 

RDUs are a bit of a pain but there is a method to the madness. Basically it saves you from doing a full install of the application every time a new update is released. Imagine downloading the full software package on a modem every time there is an update.... It also saves Dantz from testing and releasing a new build of the entire software package every time. This also makes it possible to get the updates out faster.

 

Sometimes Dantz rolls minor patches and fixes into RDUs. Apparently RDU 5.6 had some fixes to address memory management. Earlier RDUs included a fix for the elem 812 error that could occur when restoring from old backup sets. In general it is a good idea to install the latest version if you are having trouble with Retrospect.

 

Nate

Link to comment
Share on other sites

I had precisely this problem on my OSXS 10.2.8 machine. I cleared it by using a new backup set, using Onyx to repair permissions, empty caches, redo prebinding (optimize), in fact I ticked every box on the Automate tab!, and then I rebooted the server. It has been fine since.

Link to comment
Share on other sites

I can confirm that the latest RDU (5.7.104) has fixed the "elem.c-821" bug in this thread. I take Nate's point about the fix being incorporated into the RDU's, but our point is that Dantz do themselves no favours by choosing to "fix" a problem and then NOT DOCUMENT IT! Read it, there's nothing in the readme file about bug fixing, only some dross about added support for new mechanisms. Get with the program, Dantz, and document your product more thoroughly.

 

I'm glad this issue is finally resolved.

Link to comment
Share on other sites

  • 3 weeks later...

Hello again.... I just got another 821 error, so the RDU didn't help me. I was OK for a good 2 weeks though, so I thought I has been helped.

 

I will try NickG's suggestion of running Onyx and get back to you.

 

I am curious, is anyone else having this problem persist after RDU 5.7.104?

 

Eric

Link to comment
Share on other sites

I am curious, is anyone else having this problem persist after RDU 5.7.104?

 

Eric

Using Retrospect 5.0 I found the following, interesting, remark added to my assertion check:

! 9/20/2004 9:23:41 AM: System clock and tick timer appear inconsistent, code 2.

Dates, times and statistics may be incorrect.

Internal consistency check failed:

Assertion check at "elem.c-822"

 

That might shed some light on the elem.c error codes. Imho, an application should catch

all sorts of errors and handle them in the best way possible, which includes an understandable

error message to the user. When the app quits with a cryptic error message hinting some

programmer had put in a catch-all or programming debug statement, I find this a bug.

This is independent of the hardware; the program behaves differently than expected.

my hardware, by the way, is a powerbook G3/400MHz/192MB, Firewire LaCie D2 cdrw (52x24x52)

 

ard

Link to comment
Share on other sites

I ran OnyX and the server ran for the usual 2-3 days and then 821'd on me. Again, the server stopped on an oSX client and was also preceded by those supposedly irrelevant FSMake Unicode errors (when file system logging is on).

 

Where should I go from here? Right now I would put Retro in the trash if I could but there isn't anything else around that will do the multi platform job for me. But I will try to be constructive if there are any better ideas.

 

Thanks

 

Eric

Link to comment
Share on other sites

Eric,

 

Looking back over this thread, I see that on 7/22/04 you said you were looking to find support from the Sweedish vendor. Were you able to do this? You have also mentioned that you were considering swapping out RAM, but I see no mention of your doing this. Can you try this on a different Macintosh?

 

When Retrospect gets to a place where the code can no longer be executed, it logs the error and displays the assertion error dialog box. Back in OS 9 days there was the wonderful "OK Dokey" software that would click any OK button; that in conjuction to the fabulous "Keep It Up" would keep a Retrospect machine going without user intervention. The latter could probably be done with unix tools, but the former is just not available on OS X as far as I know.

 

But the key here is the assertion log that the program generates. Trouble is, it doesn't include any information helpful to anyone unless you're running a version of Retrospect that has its debug information in place. But even when you do that, the helpful information that you can get is probably helpful only to Dantz tech support or engineers.

 

So your best bet is to find a way to work with them. Perhaps Nate can help to arrange for the necessary software and lead you to a way where you can get the help you need directly from Dantz. This will require one of their "Support Incidences," which might cost money, or you might have one that was included in your 5.1 -> 6.0 upgrade. I have no experience with Dantz international tech support, but they do offer it so they must have methods in place.

 

Dave

Link to comment
Share on other sites

Thanks Dave,

 

I talked and emailed with the Swedish distributor for Dantz (moreware). They had never heard of the problem and actually emailed me this very thread as a solution! Amusing but not very helpful. I have also been in touch with SONY and they explained that there probably wasn't anything wrong with my drive. The testing tool they provide doesn't actually support firewire and La Cie has no info at all on what they put in their boxes.

 

I just ordered new memory for the server, so I will replace it all on Monday. If the error comes back, it should surface after a few days. Then I will call Tech Support in Europe. I just feel very reluctant to call up some people in Holland or somewhere only to have them charge me money (I think I had support included only for the first 30 days) and take forever going through things I already know.

 

But if I call them I will be sure to share with the forum. It would be great if I could generate some useful logs and have someone to send them to.

 

I will post here as soon as I have tried the RAM and/or called Euro Tech Support.

 

 

PS, Yes OS9, those were the days! OK Dokey ....

Link to comment
Share on other sites

Just curious... I still get the elem.c-821 assertion failure with rdu1.7. I've downloaded rdu1.8 but I haven't tried it yet and was just wondering if any progress had been made. I have not filed a 'support request' since I am not going to pay money to help debug an ASSERTION FAILURE, i.e. a program error. I would be willing to help debug but I am not willing to go through a pay first, get refund later cycle. Here's hoping that Dantz recognizes the problem. S!

Link to comment
Share on other sites

  • 2 weeks later...

I pulled out the old RAM (512 + 256 in slots "1" and "3") and replaced them with 2 new 512s in slots 1+2. This config has been running for over a week without an 821 error. I don't know if the problem was in the RAM or possibly in the slots since I slightly changed both. I will see if the server is still alive on Monday.

 

eric

Link to comment
Share on other sites

  • 2 weeks later...

Well, I've been chasing this problem for almost 3 weeks. I've tried everything, and with little help from technical support, I am coming to the conclusion that this is a problem with the software. I have switched hardware, tapes, reinstalled, un-installed. Maybe I should call my executive friends at EMC and tell them that Dantz has customer no-service when trying to solve this problem. It's amazing when the tech guy tells you to look at the forum for support, and "I've never heard of the problem". From this I think Dantz/EMC needs to take a look at all these problems. I've been a loyal Retrospect user (Server/Client) for 6 years, and I've never had a problem like this. At the cost of lost productivity, I'm going to start looking for another alternative. Thanks Dantz but you guys got something broken in tech support and are going to loose me as a customer!

Link to comment
Share on other sites

I have also been very close to losing Retrospect and switching to something else for the 821 error (and others...) I have been using RS since v.4 and have had different problems come and go.

 

In this particular instance (821 error), putting new memory in the server actually fixed the problem. Really bisarre but true. I still don't understand how all other software manages with my "faulty" memory, but this worked for me.

 

Have you tried that?

Link to comment
Share on other sites

Sometimes you guys really crack me up!

 

>In this particular instance (821 error), putting new memory in the server actually fixed the problem.

>Really bisarre but true. I still don't understand how all other software manages with my "faulty"

>memory, but this worked for me.

 

Most likely none of the other programs you use build large file-trees and write them to RAM. Retrospect does, and thus stressed your faulty hardware to the point of failure.

 

Back in April of 2002, Adam Engst wrote in TidBITS that Retrospect was "often an electronic canary in the digital mines."

http://db.tidbits.com/getbits.acgi?tbart=06775

So it's not at all bizarre for Retrospect to fail under a faulty hardware configuration, just as it's not bizarre for the program to operate properly when that hardware was replaced.

 

If Tom Parsons opened a support incident with Dantz technical support and they told hm that they'd never heard of assertion check errors (at either elem.c-821 or elem.c-811, Tom doesn't report which he is experiencing) then that would certainly be cause for concern. There is an assertion log generated by these failures, and tech support can provide users with a debug version of the software that might help track down the problem.

 

Here on the Forum, it's usually necessary to list hardware/software configurations in detail; things such as unsupported SCSI cards, outdated card drivers, etc, can often be the cause of Retrospect errors. And as shown by ericrow's experience, faulty memory should never be ruled out.

 

Dave

Link to comment
Share on other sites

Tom,

 

Did you actually speak with Tech Support or with a customer service rep?

 

Each elem.c assert error is unique and could have different troubleshooting for every user who sees it.

 

The most common cause is memory corruption or something specific to the computer. Trying Retrospect on another computer is often the best troubleshooting because it can tell you if the issue is computer specific or not.

 

We can do some additional troubleshooting via tech support, I am sure your incident would still be open. We can even get advanced logs for our engineers to review. Hopefully the log would should more then just memory issues. Make sure you try 6.0.204 that was released this week too.

 

Have you checked out the Assert Solution Finder in the knowledgebase?

Have you reviewed:

 

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

Link to comment
Share on other sites

hi all...

 

I'm sorry Dave but I have to respectfully disagree.

I use memory hogs, such as Mathematica, frequently but only Retrospect is giving me problems. For tech support not to peruse the Forums from time to time to survey what problems people are having is a mistake.

After at least 6 months of discussion of this problem on the forums, it seems that tech support is still not aware of the problem. Am I the only one who doesn't see a problem with this?

 

The "canary" excuse which I have heard repeated many times just doesn't cut it. If Retrospect is so fragile(?) perhaps Dantz should consider more informative messages and a more robust design. I have had this problem on both machines that I have used retrospect on using different drives, different scsi cards, different memory, different cables and different tapes. Now, there may still be undetected hardware/system problems with both machines but if Retrospect is the only software failing as a result then there IS a problem with Retrospect.

 

With the exception of one other company whose name I wont mention, Dantz is at the bottom of my personal favorites list. Fortunately for them they have a monoply in the Apple market for backups to tape. I don't like companies that seem to go out of their way to make it difficult for customers.

 

I am glad for 'ericrow' that his problem seems to be fixed. For me the problem is intermittent; even though I haven't had it occur for a week or so I am not willing to say that its gone.

 

May all your backups be trouble-free and never needed...

 

RickB

Link to comment
Share on other sites

Archived

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


×
×
  • Create New...