Jump to content

Assertion failure at "elem.cpp-855"


Recommended Posts

Hi All,



I seem to have found a new bug. I am running a Win2k server using retrospect single server, to backup PC and MAC clients. Since about a week ago, the script has been crashing retrospect, with this error message. I can find nothing in the FAQ about it... has anyone else had retrospect crash like this? Any way around it?


I took a screenshot of the error, it is here




and the assert_log.utx which it appends is here




Please help, our institute is currently not being backed up, except for manually..




nick langdale



Mathematical Sciences Institute

Australian National University

Link to comment
Share on other sites

Actually we are aware of this error in several cases. It is being fixed in our next release.


Known causes:


Some duplicate type scripts can fail when they have a bogus destination


Selecting an empty backup set for Disaster Recovery


Some restores under specific configuations have seen this error


Backup or Restore of HFS Standard data to HFS+ volume


This error may happen under other conditions, but basically it should be fixed in our next release. A date is not yet available for our next release.

Link to comment
Share on other sites

I have this exact same bug. I was getting similar crashes in 5.6, but it was clear to me you guys had absolutely no interest in fixing that version since you've changed revenue models. So I spent an additional $500 to upgrade to 6.0. Still not fixed!




For a company who claims on their homepage that "the company's patented technologies provide the reliability and efficiency that small and midsize businesses depend on", it is not acceptable to say, "fixed in next release, no date available". That's not very dependable. Put the fix in for this bug and give those who have this problem an early release or patch. What the heck do you expect us to do for backup while I wait for your next release?




(1) I'm not running a duplicate script - it is the so-called "proactive" script.


(2) I'm not doing anything with disaster recovery.


(3) I'm not doing a restore.


(4) This is a PC, so I obviously am not backing or restoring to a HFS+ volume.




What is the workaround?






The only clue is that shortly before the crash, I got the following in my log. BTW, I got this in version 5.6 as well.




- 2003-02-19 6:30:01 PM: Copying $[*!20612,,14,+3] (C:)$[3] on Demo$[4]


2003-02-19 6:30:01 PM: Connected to $[*!20780,,14,+3]Demo


VPcFsNodeInfo::NetImport - elsize 4, sz -31,181


PcFsVolNodeScan::NetImport (node) - elsize 0, sz -31,181


$[*20750] Scanning incomplete, error -3102 (unknown) $[126901530011820000]






This bug has been reported in the past on this forum (including the elem.cpp assert), but was never followed up on, apparently.




http://forums.dantz.com/ubbthreads/showflat.php?Cat=&Board=multiserver&Number=20400&Forum=All_Forums&Words=vpcfsnodeinfo&Match=Entire%20Phrase&Searchpage=0&Limit=25&Old=allposts&Main=20400&Search=true#Post20400]Big URL

Link to comment
Share on other sites

I found a few notes about the -3102 error message.


From the Knowledgebase: This error may be caused by a problem communicating with the Client computer on the network. If this problem is isolated to a specific client on the network, then it may be necessary to try testing a different ethernet card on the client computer.


One customer had a "SMC easy ethernet card" that was causing the error. He replaced the card and the error want away.


Does the error happen every time you back up "Demo"? If so then I woud look for problems in that PC's NIC card. In your case, you may want to update the ethernet drivers on "Demo" and maybe consider swapping out the ethernet card.


If the assert error happens when accessing a specific client on the network, then a bad network packet could be contributing to the crash.

Link to comment
Share on other sites

You are not alone... I'm having the same and other similar problems.


My current workaround is to manually backup my problem workstations... and remove them from my automatic backup schedules... pretty lame but at least I know when retrospect crashes and I can restart it... and it doesn't interfere with all my other clients’ backup schedules.


I have 2 machines that get the -3102 NIC adapter error... same NICs... could both be bad or does Retrospect not support Dell integrated Intel Gigabit NICs?


Link to comment
Share on other sites

>Dell integrated Intel Gigabit NICs?



Retrospect should work with all stock Dell hardware, including the above ethernet cards.


I am doing some added research here at Dantz to make sure this assert error is resolved based on the symptoms described in this thread.

Link to comment
Share on other sites



Glad to see that something is being done. I narrowed the problem down to one particular client, with an "Intel 201 Based PCI Ethernet Adaptor". This client will ALWAYS fail on automatic (scripted) backup, and i have just discovered, will ALWAYS fail even on manual backup. (im looking at the elem.cpp-855 error right now).


I'll see if i can change the netcard, but is this particular NIC an adaptor which is known to be troublesome?


Also, if this error will "basically be fixed" in the next release, will there still be some NIC's which could be cause for concern?







Link to comment
Share on other sites


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

  • Create New...