Opened 8 years ago

Closed 8 years ago

Last modified 2 years ago

#4263 closed defect (fixed)

TBB on Mac OS X 10.5.8 fails to run

Reported by: ioerror Owned by: erinn
Priority: Immediate Milestone:
Component: Applications/Tor bundles/installation Version:
Severity: Normal Keywords:
Cc: mikeperry, ioerror, g.koppen@… Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

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.

Child Tickets

Attachments (1)

ticket-4263-vidalia-0.2.2.35-6-otool.txt (8.2 KB) - added by phobos 8 years ago.
otool -l output from tbb 0.2.2.35-6-dev-ix86 32bit

Download all attachments as: .zip

Change History (26)

comment:1 Changed 8 years ago by mikeperry

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 is similar.

comment:2 Changed 8 years ago by Sebastian

Owner: changed from helix to erinn
Status: newassigned

reassigning to erinn, there's no helix on trac

comment:3 Changed 8 years ago by erinn

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?

comment:4 Changed 8 years ago by gk

Cc: mikeperry ioerror g.koppen@… added; mikeperry ioerror removed

comment:5 Changed 8 years ago by phobos

tbb 0.2.2.34-2 tbb runs just fine on 10.5.8 x86.

sw_vers output:
ProductName: Mac OS X
ProductVersion: 10.5.8
BuildVersion: 9L30

comment:6 Changed 8 years ago by 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

comment:7 in reply to:  6 Changed 8 years ago by phobos

Replying 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

comment:8 Changed 8 years ago by phobos

and for added fun, here's the output of otool -l, which shows a bunch of missing libs, attached.

Changed 8 years ago by phobos

otool -l output from tbb 0.2.2.35-6-dev-ix86 32bit

comment:9 Changed 8 years ago by 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?

comment:10 Changed 8 years ago by phobos

0.2.2.35-5-dev 32bit runs fine on osx 10.5.8.

0.2.2.35-7-dev 32bit has the same problems as 0.2.2.35-6.

comment:11 in reply to:  9 Changed 8 years ago by mijk

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.

comment:12 Changed 8 years ago by mijk

Cc: mijk.bee@… added

comment:13 Changed 8 years ago by mikeperry

Component: Tor BrowserTor bundles/installation

comment:14 Changed 8 years ago by groksteady

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.

comment:15 Changed 8 years ago by 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?

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 trap

extended:

$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 0

Errorlog (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?

comment:16 in reply to:  15 ; Changed 8 years ago by 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.

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.

comment:17 in reply to:  16 ; Changed 8 years ago by mijk

Status: assignedneeds_review

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:

  1. Using the correct compiler parameters:

gcc-4.2 -mmacosx-version-min=10.5 -isysroot /Developer/SDKs/MacOSX10.5.sdk...

  1. 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 binary

The 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)

comment:18 in reply to:  17 ; Changed 8 years ago by Sebastian

Status: needs_reviewassigned

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:

  1. Using the correct compiler parameters:

gcc-4.2 -mmacosx-version-min=10.5 -isysroot /Developer/SDKs/MacOSX10.5.sdk...

  1. 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 binary

The 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.

comment:19 in reply to:  18 Changed 8 years ago by mijk

Cc: mijk.bee@… removed

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.

comment:20 Changed 8 years ago by phobos

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

comment:21 Changed 8 years ago by Sebastian

Status: assignedneeds_review

Fix is in branch macx86 in my repo, due to be merged soon

comment:22 Changed 8 years ago by arma

Looks like it's merged, and at least some 10.5.8 users are happy?

comment:23 Changed 8 years ago by phobos

I can confirm that tbb runs on 10.5.8 just fine now.

comment:24 Changed 8 years ago by Sebastian

Resolution: fixed
Status: needs_reviewclosed

comment:25 Changed 2 years ago by teor

Severity: Normal

Set all tickets without a severity to "Normal"

Note: See TracTickets for help on using tickets.