New Leopard Server, New Retrospect, and a crasher

[mattd]

I just installed Leopard Server on new hardware, and a fresh install of Retrospect (latest release.)

 

I've tested a reliable backup once logged in; however, when I try to leave it unattended, (and I leave my machine unattended at the login window) it crashes:

 

Jul 7 02:00:05 mail Retrospect[548]: 3891612: (connectAndCheck) Untrusted apps are not allowed to connect to or launch Window Server before login.

Jul 7 02:00:05 mail /Applications/Retrospect 6.1/Retrospect.app/Contents/MacOS/Retrospect[548]: _RegisterApplication(), FAILED TO establish the default connection to the WindowServer, _CGSDefaultConnection() is NULL.

Jul 7 02:00:09 mail ReportCrash[550]: Formulating crash report for process Retrospect[548]

Jul 7 02:00:09 mail ReportCrash[550]: Saved crashreport to /Library/Logs/CrashReporter/Retrospect_2008-07-07-020009_mail.crash using uid: 0 gid: 0, euid: 0 egid: 0

 

Any ideas on this?

[Mayoff]

Try to check the option to not backup ACLs in the preferences.

[mattd]

I'll try that; please note that the build released on 6/30 supposedly fixes the ACL crasher on 10.5.

 

This problem occurs even before the backup starts. Apple doesn't allow people to attach the WindowServer when the user is logged out; so the net-net is that it can't display the UI, and causes a crasher.

 

The odd thing is that in the background, it seems to run and finish. I have no idea how this build got through qualification into public release (with Panther support no less) when it clearly doesn't work properly.

[CallMeDave]

I just installed Leopard Server on new hardware, and a fresh install of Retrospect (latest release.)

 

"latest release" is a relative description. It would help current and future readers if you would document the version of Retrospect and the RDU that you are using.

 

Apple doesn't allow people to attach the WindowServer when the user is logged out; so the net-net is that it can't display the UI, and causes a crashe

 

Actually, Apple was going to do that for Tiger, and told developers in advance of 10.4 that GUI programs would need a new method if they wanted to run before users. But then Apple changed "their" mind(s) and continued to allow WindowServer access.

 

I'm hard pressed to believe that Leopard changed things, as so far yours is the first report on the Forum of this behavior.

 

I have no idea how this build got through qualification into public release ... when it clearly doesn't work properly.

 

For you.

 

Perhaps it's a software defect. Perhaps it's an OS X internal change that broke some otherwise defect free code. Perhaps it's something specific to your machine, and seeing what's been written to /Library/Logs/CrashReporter/Retrospect_2008-07-07-020009_mail.crash might help.

 

IMHO it's a little premature to pin the blame on any specific process until more is known.

[rhwalker]

please note that the build released on 6/30 supposedly fixes the ACL crasher on 10.5.

Sorry, you are mistaken. The June 30, 2008, update has the same preference that has been present for over a year as a workaround for an Apple bug in the Carbon API libraries.

 

The release notes and the KB article about the ACL bug are wrong, and have been since day one. This has nothing to do with 10.5.x, has nothing to do with particular versions of 10.4.x, and has nothing to do with Intel vs. PPC platforms.

 

The ACL libraries for the "Universal Binary" version of Mac OS X and Mac OS X Server have a bug that cause certain syscalls to malfunction for Carbon API programs (which Retrospect, because of its ancient codebase, is). The Universal Binary version of Mac OS and Mac OS X Server is a very different animal, even for the same 10.4.x releases, from the PPC-only version, and was never released for the PPC platform, although, if you know what you are doing, can be installed on the PPC platform, and many Mac OS X server users did so as a workaround for some AFP bugs in Mac OS X 10.4.x Server for PPC.

 

ACLs were never enabled for Mac OS X non-server 10.4.x, but you could enable them using the command line if you knew what you were doing. ACLs were enabled by default for Mac OS X Server 10.4.x, but PPC Mac OS X Server 10.4.x, which was not the "Universal Binary" version of 10.4.x Server, did not have this particular bug.

 

Thus the erroneous folklore, perpetuated in the Retrospect release notes and Retrospect KB article, regarding certain versions of 10.4.x and Intel platform. Mac OS 10.5.x (server and non-server) is only available in the "Universal Binary" version.

 

Bottom line, every "Universal Binary" version of Mac OS X (10.4.x and 10.5.x, server and non-server) has this Apple bug for programs that use the Carbon API. As a workaround, because Apple has never fixed this bug, EMC's programmers provided a preference setting to not back up ACLs (and thus, to not use the problematic syscalls that trigger this bug). This preference setting has been around for over a year in Retrospect.

 

While this bug will apparently never go away, when the rumored "Universal Binary" (Cocoa API, rather than Carbon API) version of Retrospect X goes into beta later this year (hopefully), this will become a non-issue because it will not use the Carbon API.

 

Until then, Retrospect cannot back up the ACL metadata. If you have a complex ACL setup, you will have to reconfigure that by hand after a restore. Most people do not have such a setup, and instead inherit ACLs from the parent in the directory tree.

 

Clear?

 

I have no idea how this build got through qualification into public release (with Panther support no less) when it clearly doesn't work properly.

You should have participated in the public beta program. Bugs were found and fixed. I suggest that you participate in the public beta for Retrospect X to ensure that your concerns are addressed for that release.

 

Russ

 

Edited July 7, 2008 by Guest
beta participation

[mattd]

I find the tone in this forum shocking. To address your "comments":

 

- I did request access to the beta program.

 

- The problem with the crasher occurs WAY before a backup even starts; it's on launch.

 

- As for your comment about "folklore" -- if build 138/release 230 doesn't address this, then the readme (posted on 6/30/08) needs some attention -- it claims the OS update solves the problem -- and if it isn't true, it's unconscionable:

 

Backing up ACLs on Intel Macs: There is a bug in Mac OS 10.4.7, 10.4.8, and 10.4.10 that causes Retrospect to crash when backing up ACLs. To help alleviate this issue we have added an option to the preference to not back up ACLs on Intel Macs. If you are running into this problem the solution is to update the OS to 10.4.9 or 10.5 or to check the box to turn off the option to back up ACLs.

 

Running Retrospect and Retrospect Client on Mac OS X 10.4 (Tiger): This release of Retrospect provides complete support for Mac OS X Tiger, including:

 

Access Control Lists (ACLs): Mac OS X Server 10.4 (Tiger Server) added support for ACLs. ACLs allow for finer grained control of the permissions set on files and folders. Retrospect can back up, restore, and duplicate ACLs.

Extended attributes: Mac OS X Tiger introduced support for extended attributes. Retrospect can back up, restore, and duplicate extended attributes.

Edited July 7, 2008 by Guest

[mattd]

Hi Dave, I'm on build 138 - release 230, released 6/30/08.

 

My personal opinions:

 

- The Window Server attach is something that has been removed for security reasons. (And a good thing.)

 

- IMHO, the Carbon vs. Cocoa thing really doesn't have anything to do with it: faceless background applications have been around for years. There's nothing stopping EMC from separating the FE and BE and doing it in Carbon. Agreed, Carbon is probably not a good long-term direction, but it would be a start.

Edited July 7, 2008 by Guest

[Mayoff]

I have updated the KB article to more accurately reflect the ACL issue.

 

Does the Retrospect log report any errors at the same time as the system error?

 

6.1.138 has been out for a long time, and I too have not seen this issue before. I don't even know what "WindowServer" is, so it is hard for me to offer suggestions.

 

If you leave the Mac logged in, but running backups do you get the same failure?

[CallMeDave]

My personal opinions:

 

- The Window Server attach is something that has been removed for security reasons. (And a good thing.)

 

Whether or not Apple has made a structural change is not a matter of opinion. Those of us who regularly troll here on the Forum aren't programmers, so I for one am not in a position to comment on the status of WindowServer access in whatever version of Mac OS X 10.5.x Server you are using (you didn't specify). (for Robin, you can consider "WindowServer" to be the application that presents the user with the login window, showing the cute icons and user names)

 

As to the relative goodness of such a move, that's a perfectly reasonable opinion to hold.

 

 

- IMHO, the Carbon vs. Cocoa thing really doesn't have anything to do with it: faceless background applications have been around for years. There's nothing stopping EMC from separating the FE and BE and doing it in Carbon. Agreed, Carbon is probably not a good long-term direction, but it would be a start.

 

Well, Carbon vs. Cocoa has _everything_ to do with this. Retrospect 5 was born from Carbon (as is all life). But what's "stopping" EMC from making major changes in the current code base is, well, everything. They don't have unlimited programmers sitting in front of unlimited workstations with unlimited time to spring forth either the complete works of Shakespeare or a new revision of Retrospect that works around depreciated and buggy operating system code. Instead, they have put their resources on track to code and publish a new version that doesn't use legacy hooks.

[Mayoff]

Can you post the crash log itself. That may help us understand the failure.

 

Saved crashreport to /Library/Logs/CrashReporter/Retrospect_2008-07-07-020009_mail.crash

 

[mattd]

Hi Robin,

 

I'll post a crashlog for you. Thanks for making the updates.

 

The crash happens ONLY in unattended mode at the login window. It does NOT happen when running logged in, even when ACLs are being backed up. So I think this whole ACL issue on the current build on 10.5.4 is a red herring.

 

There were a number of security changes in 10.5.4 which may be impacting the way the application interacts with login window. I'll walk through the crash log again but nothing on the surface seems obvious other than a bad core graphics port. This **could be** an artifact of a video driver problem/bug possibly. I've seen this before in the past -- I had a bad QuickTime install and Retrospect calls an image decompressor in the quicktime framework to show the startup image. Need to do more checking.

[mattd]

Well, factoring code out is something that has been a staple of every WWDC I've attended going back to the Copland days.

 

The issue of Carbon vs. Cocoa has nothing to do with app architecture. This Cocoa rules the earth stuff is being spouted by marketing people which unfortunately has got nothing to do with these issues. For what it's worth, the Finder is still Carbon. I understand that it's tough to port boatloads of code-- believe me, I understand that! But the issue here is you have to start at some point.

 

Not trying to detract from Cocoa, it's very powerful. But this issue I think is different. We need the core of retrospect spun off as a faceless service. That would be a huge start.

[CallMeDave]

We need the core of retrospect spun off as a faceless service.

 

That's exactly the plan, as announced by EMC at the most recent (2008) Macworld.

[Mayoff]

Yes, that will happen in Retrospect X

[rhwalker]

I find the tone in this forum shocking. To address your "comments":

 

- I did request access to the beta program.

 

- The problem with the crasher occurs WAY before a backup even starts; it's on launch.

 

- As for your comment about "folklore" -- if build 138/release 230 doesn't address this, then the readme (posted on 6/30/08) needs some attention -- it claims the OS update solves the problem -- and if it isn't true, it's unconscionable: ...

Matt,

 

I'm truly sorry if my "comments" or their tone offended you; I was simply trying to help. In the future, I won't offend you again by trying to help you.

 

From your posturing remarks that you had no idea how this build could get through qualification into public release, and from the fact that I never saw you post this particular bug in the beta forum for the client, I could only assume that you had not participated in the beta program. Please accept my apology for my error caused by incomplete information.

 

From your remarks, then, I can only assume that you reported this crashing bug privately to the developers in ample time for the developers to address it, because they did address many issues that were reported, and that they ignored your bug report(s). Again, my error, and I apologize.

 

- As for your comment about "folklore" -- if build 138/release 230 doesn't address this, then the readme (posted on 6/30/08) needs some attention -- it claims the OS update solves the problem -- and if it isn't true, it's unconscionable:

The release note's readme (as all Retrospect release notes seem to have been since at least 1992 when I started using the program) seemed to be an edit of the prior update's release notes, prepending information about the new release, so that the release note was cumulative. The whole point of my post was to clarify this for you and to correct what seemed to be your misunderstanding. Sorry for trying to clear this up.

 

There was nothing in my post concerning Carbon vs. Cocoa and the GUI. All that I was trying to address was the source of the crashing bug and that it was unlikely to be fixed prior to the release of Retrospect X.

 

It seems that you take offense easily, at simple typos in release notes, in bugs that slip through EMC's QC/QA and the beta test program, and in attempts by other users to help you in this forum.

 

I don't work for EMC/Dantz/Insignia/whatever. I was just trying to help. Sorry to have offended you, that wasn't intended at all.

 

Regards, and have a nice day,

 

Russ

[CallMeDave]

Hey Russ, I enjoy well-directed snark as much as the next interdweeb, but the original post was pretty clear that this had nothing to do with clients. And since the beta program was setup only to support the new universal Retrospect Client software, I'm not sure how participation in the Unicorn program might have been expected to discover what is being reported here.

 

And if this is a 10.5.4 or 10.5.4 Server only issue, that also might have remained undiscovered until after 6.1.222 was signed off on.

 

- Mattd, is "RetroRunSL" running on the machine in question before/after the crash?

- What model of Macintosh is this?

 

 

 

 

 

 

 

Edit:

OK, I just tried a quick and dirty test:

 

iMac Core Duo

Mac OS X 10.5.4 9E17

Retrospect 6.1.222

RDU 6.1.14.101

 

- Configure Script (Destination: File Backup Set, Source: /usr/bin/)

- Schedule for short time in the future (8:15 pm)

- Log out

- Observe Retrospect launch (LoginWindow obscures progress window, but menu bar and cursor changes confirm behavior)

- Retrospect Special->Preferences->Unattended was set to "Stay in Retrospect" so Retrospect's cursor and menu bar items remained until I clicked on login identity and entered account password; was correctly prompted by Retrospect to authenticate before being allowed to interact with the still-running program.

- Observe Retrospect Operations Log; confirms "execution completed successfully."

 

BUT

 

A trip to Console reveals errors in system.log, same as reported upthread (edited for visual clarity):

 

daveiMac (CGSLookupServerRootPort) Untrusted apps are not allowed to connect to or launch Window Server before login.

daveiMac Retrospect[536]: kCGErrorRangeCheck : On-demand launch of the Window Server is allowed for root user only.

daveiMac /Applications/Retrospect 6.1/Retrospect.app/Contents/MacOS/Retrospect[536]: LaunchServices/5123589: Unable to lookup coreservices session port for session 0x0 uid=501 euid=0

daveiMac /Applications/Retrospect 6.1/Retrospect.app/Contents/MacOS/Retrospect[536]: _RegisterApplication(), FAILED TO GET ASN FROM CORESERVICES so aborting.

daveiMac ReportCrash[537]: Formulating crash report for process Retrospect[536]

daveiMac ReportCrash[537]: Saved crashreport to /Library/Logs/CrashReporter/Retrospect_2008-07-07-201505_DavidiMac.crash using uid: 0 gid: 0, euid: 0 egid: 0

 

 

Opening CrashReporter's log, it reads:

 

Process: Retrospect [536]

Path: /Applications/Retrospect 6.1/Retrospect.app/Contents/MacOS/Retrospect

Identifier: Retrospect

Version: ??? (???)

Code Type: PPC (Translated)

Parent Process: launchd [1]

 

Date/Time: 2008-07-07 20:15:05.515 -0700

OS Version: Mac OS X 10.5.4 (9E17)

Report Version: 6

 

Exception Type: EXC_CRASH (SIGABRT)

Exception Codes: 0x0000000000000000, 0x0000000000000000

Crashed Thread: 0

 

Thread 0 Crashed:

0 translate 0xb8152b34 spin_lock_wrapper + 91256

1 translate 0xb8171633 CallPPCFunctionAtAddressInt + 96207

2 translate 0xb80bdb8b 0xb8000000 + 777099

3 translate 0xb80b7007 0xb8000000 + 749575

4 translate 0xb80d49c0 0xb8000000 + 870848

5 translate 0xb813ce79 spin_lock_wrapper + 1981

 

Thread 1:

0 ??? 0x800bc4a6 0 + 2148254886

1 ??? 0x800c3c9c 0 + 2148285596

2 translate 0xb818b6ea CallPPCFunctionAtAddressInt + 202886

3 ??? 0x800ed6f5 0 + 2148456181

4 ??? 0x800ed5b2 0 + 2148455858

 

Thread 0 crashed with X86 Thread State (32-bit):

eax: 0x00000000 ebx: 0xb81715c2 ecx: 0x00000000 edx: 0x00000006

edi: 0x00000218 esi: 0x00000000 ebp: 0xb7fff978 esp: 0xb7fff958

ss: 0x0000001f efl: 0x00000246 eip: 0xb8152b34 cs: 0x00000017

ds: 0x0000001f es: 0x0000001f fs: 0x00000000 gs: 0x00000037

cr2: 0xffe2a050

 

Binary Images:

0xb8000000 - 0xb81d7fe7 translate ??? (???) /usr/libexec/oah/translate

 

Translated Code Information:

NO CRASH REPORT

 

 

 

 

I saw no indication of Retrospect crashing at the time reported in the crash log. Nothing up my sleeve, Presto!

Dave

Edited July 8, 2008 by Guest
Testing