TBB on Mac OS X 10.5.8 fails to run
Erinn,
I've privately sent you two crash dumps that are full of personal info - this was the file that created them:
https://www.torproject.org/dist/torbrowser/osx/TorBrowser-2.2.33-3-dev-osx-i386-en-US.zip
This is the crash that I can share easily:
Process: firefox-bin [60516] Path: ../..//Contents/MacOS/Firefox.app/Contents/MacOS/firefox-bin Identifier: firefox-bin Version: ??? (???) Code Type: X86-64 (Native) Parent Process: Vidalia [60514]
Interval Since Last Report: 477 sec Crashes Since Last Report: 1 Per-App Interval Since Last Report: 0 sec Per-App Crashes Since Last Report: 1
Date/Time: 2011-10-18 19:33:52.968 -0700 OS Version: Mac OS X 10.5.8 (9L30) Report Version: 6 Anonymous UUID: 64A8470D-2A63-48A7-BD3D-A58B27B339A1
Exception Type: EXC_BREAKPOINT (SIGTRAP) Exception Codes: 0x0000000000000002, 0x0000000000000000 Crashed Thread: 0
Dyld Error Message: unknown required load command 0x80000022
TBB totally fails to run on this machine.
Activity
I swear we've seen this 0x80000022 error a few different places related to using the wrong/outdated Xcode utils.. I can't find the exact bug I'm thinking about, but #2813 (closed) is similar.
After carefully re-reading the emails you sent me and this bug report, my question is: which bundle is the user actually using? The email says x86_64 which definitely won't work on 10.5.8 -- that is only built with the 10.6 SDK, and the crash logs are exactly what I was seeing when the i386 bundle wasn't being built with the 10.5 backwards compatibility options. Can you verify which bundle is being used, and ask theuser (re-)try the i386 to double check?
Trac:
Cc: mikeperry ioerror to mikeperry, ioerror, g.koppen@jondos.detbb 0.2.2.35-6 fails to run on 10.5.8 x86:
The basic error is:
dyld: unknown required load command 0x80000022 Trace/BPT trapMore details of the error are:
dtruss ./Vidalia dyld: unknown required load command 0x80000022 SYSCALL(args) = return getpid(0x0, 0x0, 0x0) = 68753 0 __sysctl(0xBFFFE038, 0x3, 0xBFFFF458) = 0 0 open_nocancel(".\0", 0x0, 0x0) = 3 0 fstat64(0x3, 0xBFFFDDB4, 0x0) = 0 0 fcntl_nocancel(0x3, 0x32, 0xFFFFFFFFBFFFF038) = 0 0 close_nocancel(0x3) = 0 0 stat64("/Users/phobos/Downloads/TorBrowser_en-US.app/Contents/MacOS/Vidalia.app/Contents/MacOS\0", 0xBFFFDD48, 0xFFFFFFFFBFFFF038) = 0 0 issetugid(0xBFFFF038, 0xBFFFDD48, 0xFFFFFFFFBFFFF038) = 0 0 sigprocmask(0x1, 0x0, 0xBFFFDDCC) = 0x0 0 sigaltstack(0x0, 0xBFFFDDC8, 0xBFFFDDCC) = 0 0 write_nocancel(0x2, "dyld: unknown required load comm\0", 0x20) = 32 0 write_nocancel(0x2, "and 0x80000022\n\0", 0xF) = 15 0Replying to phobos:
tbb 0.2.2.35-6 fails to run on 10.5.8 x86:
The basic error is: {{{ dyld: unknown required load command 0x80000022 Trace/BPT trap }}}
More details of the error are: {{{ dtruss ./Vidalia dyld: unknown required load command 0x80000022 SYSCALL(args) = return getpid(0x0, 0x0, 0x0) = 68753 0 __sysctl(0xBFFFE038, 0x3, 0xBFFFF458) = 0 0 open_nocancel(".\0", 0x0, 0x0) = 3 0 fstat64(0x3, 0xBFFFDDB4, 0x0) = 0 0 fcntl_nocancel(0x3, 0x32, 0xFFFFFFFFBFFFF038) = 0 0 close_nocancel(0x3) = 0 0 stat64("/Users/phobos/Downloads/TorBrowser_en-US.app/Contents/MacOS/Vidalia.app/Contents/MacOS\0", 0xBFFFDD48, 0xFFFFFFFFBFFFF038) = 0 0 issetugid(0xBFFFF038, 0xBFFFDD48, 0xFFFFFFFFBFFFF038) = 0 0 sigprocmask(0x1, 0x0, 0xBFFFDDCC) = 0x0 0 sigaltstack(0x0, 0xBFFFDDC8, 0xBFFFDDCC) = 0 0 write_nocancel(0x2, "dyld: unknown required load comm\0", 0x20) = 32 0 write_nocancel(0x2, "and 0x80000022\n\0", 0xF) = 15 0 }}}
The file I downloaded, verified and used is TorBrowser-2.2.35-6-dev-osx-i386-en-US.zip
Replying to erinn:
There's a new Vidalia in this release, so that might be the culprit. Can you try replacing TorBrowser_en-US.app/Contents/MacOS/Vidalia.app with the Vidalia.app from 0.2.2.35-5 and let me know if that one runs?
I can confirm that proposed process works (after replacing Vidalia.app, Vidalia starts, Firefox 10.0.2 starts and succesfully connects to the Tor network).
Tried TBB 2.2.35-7 32bit (with Vidalia.app from 0.2.2.35-5) on Mac OS X 10.5.8.
Trac:
Username: mijk-
Trac:
Username: mijk
Cc: mikeperry, ioerror, g.koppen@jondos.de to mikeperry, ioerror, g.koppen@jondos.de, mijk.bee@gmail.com -
Hi all, this is my first time posting to a bug tracker, so I apologize in advance if I'm contributing incorrectly/incompletely.
I just tried the above with the new 0.2.3.12 alpha browser bundle for Mac. That bundle did not open for me at all; when I opened the package contents and ran Tor Browser Bundle, it failed showing error -10810.
I read this ticket and tried replacing Vidalia from Browser Bundle 2.2.35-5 for i386. Now Vidalia opens and connects to Tor, but Firefox never starts. If I open try to open Firefox form its package contents, the terminal shows this:
rickv$ /Users/rickv/Applications/TorBrowser_en-US.app/Contents/MacOS/Firefox.app/Contents/MacOS/firefox ; exit; 2012-03-11 14:15:58.131 firefox[51151:10b] *** _NSAutoreleaseNoPool(): Object 0x17609cc0 of class NSCFDictionary autoreleased with no pool in place - just leaking Stack: (0x93be6f4f 0x93af3432 0x2a0f16c) logout
This is on Mac OS 10.5.8.
Trac:
Username: groksteady -
It is obvious that Vidalia is the cause of the problem. If is latest Vidalia compiled different way, why not to compile it again - the same way as it was compiled for TBB 2.2.35-5?
Since 2.2.35-5 for OS X, running Vidalia via command line ends with following:
$ ./Vidalia dyld: unknown required load command 0x80000022 Trace/BPT trapextended:
$dtruss ./Vidalia dyld: unknown required load command 0x80000022 SYSCALL(args) = return getpid(0x0, 0x0, 0x0) = 6946 0 __sysctl(0xBFFFE638, 0x3, 0xBFFFFA58) = 0 0 open_nocancel(".\0", 0x0, 0x0) = 3 0 fstat64(0x3, 0xBFFFE3B4, 0x0) = 0 0 fcntl_nocancel(0x3, 0x32, 0xFFFFFFFFBFFFF638) = 0 0 close_nocancel(0x3) = 0 0 stat64("/Users/testaccount/Desktop/TorBrowser_en-US.app/Contents/MacOS/Vidalia.app/Contents/MacOS\0", 0xBFFFE348, 0xFFFFFFFFBFFFF638) = 0 0 issetugid(0xBFFFF638, 0xBFFFE348, 0xFFFFFFFFBFFFF638) = 0 0 sigprocmask(0x1, 0x0, 0xBFFFE3CC) = 0x0 0 sigaltstack(0x0, 0xBFFFE3C8, 0xBFFFE3CC) = 0 0 write_nocancel(0x2, "dyld: unknown required load comm\0", 0x20) = 32 0 write_nocancel(0x2, "and 0x80000022\n\0", 0xF) = 15 0Errorlog (above) is from the latest release (TBB 2.2.35-8 32bit, downloaded from https://www.torproject.org/dist/torbrowser/osx/TorBrowser-2.2.35-8-osx-i386-en-US.zip - a location, that isn't linked anywhere on the Tor site).
I am using above mentioned workaround, replacing distributed Vidalia.app folder with old one (last working from 2.2.35-5), however - it doesn't seems to be the right way to solve the issue (using outdated Vidalia in the new bundle)...
And another question: is this problem persisting for OS X 10.6 and 10.7 users or is it only 10.5.8 anomally?
Trac:
Username: mijk Replying to mijk:
It is obvious that Vidalia is the cause of the problem. If is latest Vidalia compiled different way, why not to compile it again - the same way as it was compiled for TBB 2.2.35-5?
Because it's not obvious what the problem is. It looks like the old build options together with new Vidalia code produce the problematic behaviour.
And another question: is this problem persisting for OS X 10.6 and 10.7 users or is it only 10.5.8 anomally?
Yes, only 10.5 is affected.
-
Thanks for quick reply, Sebastian.
Replying to Sebastian:
Replying to mijk:
It is obvious that Vidalia is the cause of the problem. If is latest Vidalia compiled different way, why not to compile it again - the same way as it was compiled for TBB 2.2.35-5?
Because it's not obvious what the problem is. It looks like the old build options together with new Vidalia code produce the problematic behaviour.
I think it is pretty obvious what's going on (ie machine used for compiling got upgraded from 10.5 to 10.6+). It's common problem, check out those articles for possible solutions: http://grauonline.de/wordpress/?p=71 and http://software.intel.com/en-us/articles/running-an-intel-compiled-binary-on-older-mac-os-x-system-gives-dyld-unknown-required-load-command-0x80000022/
And another question: is this problem persisting for OS X 10.6 and 10.7 users or is it only 10.5.8 anomally?
Yes, only 10.5 is affected.
In this case, it is obvious that the application was incorrectly built on OS X 10.6 (or newer) machine for a 10.5 machine. A developer can fix this by considering three things:
-
Using the correct compiler parameters:
gcc-4.2 -mmacosx-version-min=10.5 -isysroot /Developer/SDKs/MacOSX10.5.sdk... -
Using the correct linker settings (setting environment variable before link command). This is required, so that the OS X 10.6 linker will not use the loader command
'LC_DYLD_INFO_ONLY' (=0x80000022), because OS X 10.5 does not understand it.
export MACOSX_DEPLOYMENT_TARGET=10.5 (or setenv MACOSX_DEPLOYMENT_TARGET=10.5)#. When this is done, one can check if the application was correctly built for OS X 10.5 by running 'otool':
otool -l binaryThe correct binary should not contain any '
LC_DYLD_INFO_ONLY' load commands (only 'LC_DYLD_INFO' commands).(see the rest in blog article http://grauonline.de/wordpress/?p=71)
Trac:
Username: mijk
Status: assigned to needs_review -
Replying to mijk:
Thanks for quick reply, Sebastian.
Replying to Sebastian:
Replying to mijk:
It is obvious that Vidalia is the cause of the problem. If is latest Vidalia compiled different way, why not to compile it again - the same way as it was compiled for TBB 2.2.35-5?
Because it's not obvious what the problem is. It looks like the old build options together with new Vidalia code produce the problematic behaviour.
I think it is pretty obvious what's going on (ie machine used for compiling got upgraded from 10.5 to 10.6+). It's common problem, check out those articles for possible solutions: http://grauonline.de/wordpress/?p=71 and http://software.intel.com/en-us/articles/running-an-intel-compiled-binary-on-older-mac-os-x-system-gives-dyld-unknown-required-load-command-0x80000022/
I can't comment on this. The build maintainer claims (and I have no reason to not believe her) that the last working bundle was also built on 10.6.
And another question: is this problem persisting for OS X 10.6 and 10.7 users or is it only 10.5.8 anomally?
Yes, only 10.5 is affected.
In this case, it is obvious that the application was incorrectly built on OS X 10.6 (or newer) machine for a 10.5 machine. A developer can fix this by considering three things:
-
Using the correct compiler parameters:
gcc-4.2 -mmacosx-version-min=10.5 -isysroot /Developer/SDKs/MacOSX10.5.sdk... -
Using the correct linker settings (setting environment variable before link command). This is required, so that the OS X 10.6 linker will not use the loader command
'LC_DYLD_INFO_ONLY' (=0x80000022), because OS X 10.5 does not understand it.
{{{ export MACOSX_DEPLOYMENT_TARGET=10.5 (or setenv MACOSX_DEPLOYMENT_TARGET=10.5) }}}
#. When this is done, one can check if the application was correctly built for OS X 10.5 by running 'otool':
otool -l binaryThe correct binary should not contain any '
LC_DYLD_INFO_ONLY' load commands (only 'LC_DYLD_INFO' commands).(see the rest in blog article http://grauonline.de/wordpress/?p=71)
Thanks for the lesson. Maybe instead of putting random bugs in needs_review without actually providing patches, you could've checked out the current way things are getting built? We do set backwards compatibility options for 10.5.
Trac:
Status: needs_review to assigned-
-
Sebastian,
Thanks for the lesson. Maybe instead of putting random bugs in needs_review without actually providing patches, you could've checked out the current way things are getting built? I did, se below (typos in your build-files etc). We do set backwards compatibility options for 10.5.
Thanks for your input. I have provided complete guide on what's wrong with the latest binaries, how to check if it's correctly compiled backwards-compatible for 10.5.x on a 10.6 machine and how to link it the right way. I've tested that complete process above myself - using last git source (0.2.17) from your repository and succesfully compiled an executable, working on 10.5.8.
What more should I do? Since today, I'm going to compile backwards-compatible vidalia binary myself when the maintainer can't.
BTW - check out
/pkg/osx/build-bundle.txt, line 36 (https://gitweb.torproject.org/vidalia.git/blob_plain/HEAD:/pkg/osx/build-bundle.txt) clearly states (in regards to bundled QT compilation):MACOSX_DEPLOYENT_TARGET=10.4. See the typo? May wrongly set env. variable relate to wrongly linked binaries and copy+pasting?! Questions. Nevermind.Trac:
Username: mijk
Cc: mikeperry, ioerror, g.koppen@jondos.de, mijk.bee@gmail.com to mikeperry, ioerror, g.koppen@jondos.de Since we haven't told the community much, I published a blog post on the issue, https://blog.torproject.org/blog/tor-browser-bundle-mac-osx-and-1058
