Opened 7 weeks ago

Last modified 7 weeks ago

#32212 new defect

Tor Browser 9.0 does not restart correctly after updating from 8.5.5, on Debian stretch

Reported by: boklm Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: tbb-9.0-issues, tbb-update
Cc: mcs, brade, intrigeri Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

When updating Tor Browser 8.5.5 to 9.0 on Debian stretch, the browser does not restart after finishing the update. However, it correctly starts when manually running the start script again.

On Debian strech, the bundled libstdc++.so.6 was not needed with 8.5.5, but is needed with 9.0. The wrapper script in Browser/firefox is supposed to add the directory containing libstdc++.so.6 to LD_LIBRARY_PATH.

I am wondering if the updater is restarting the browser using Browser/firefox, or if it is instead running Browser/firefox.real (without using the wrapper script).

Child Tickets

Change History (6)

comment:1 in reply to:  description Changed 7 weeks ago by mcs

Replying to boklm:

I am wondering if the updater is restarting the browser using Browser/firefox, or if it is instead running Browser/firefox.real (without using the wrapper script).

That is likely true. From code inspection:

To get the value of the exe arg it passes to the updater, ApplyUpdate() in toolkit/xre/nsUpdaterDriver.cpp calls XRE_GetBinaryPath(), which in turn calls mozilla::BinaryPath::GetFile().

From reading xpcom/build/BinaryPath.h, on Linux the GetFile() call is basically readlink("/proc/self/exe") which if I understand things correctly will bypass our wrapper script.

One of us should confirm that this is what is happening, maybe by temporarily replacing updater with a script that logs its args. Then we should think about how to fix this problem.

comment:2 Changed 7 weeks ago by intrigeri

On a somewhat related topic (different root cause but potentially similar symptoms), for folks using torbrowser-launcher's AppArmor profiles, one needs the fixes in this PR to get LD_LIBRARY_PATH passed through: https://github.com/micahflee/torbrowser-launcher/pull/426.

comment:3 Changed 7 weeks ago by intrigeri

Cc: intrigeri added

comment:4 Changed 7 weeks ago by mcs

Thinking about this a little more, it surprises me that LD_LIBRARY_PATH would get clobbered by the updater program or by the code that starts the updater. In other words, it should not matter if the updater starts firefox.real instead of firefox.

It also surprises me that we did not notice this problem during our 9.0 alpha cycle (since we had a few updates during that time period).

comment:5 Changed 7 weeks ago by gk

Keywords: tbb-update added

comment:6 in reply to:  4 Changed 7 weeks ago by boklm

Replying to mcs:

Thinking about this a little more, it surprises me that LD_LIBRARY_PATH would get clobbered by the updater program or by the code that starts the updater. In other words, it should not matter if the updater starts firefox.real instead of firefox.

I don't think that LD_LIBRARY_PATH is getting clobbered. The issue is on systems where the bundled libstdc++.so.6 was not required with 8.5.5 (so it was not added to LD_LIBRARY_PATH by the wrapper script, when starting the browser), but is required with 9.0.

It also surprises me that we did not notice this problem during our 9.0 alpha cycle (since we had a few updates during that time period).

I think the problem only happens with the esr60 -> esr68 updates, but not with esr68 -> esr68 updates. With the first esr68 alpha, we had #31646 which prevented the browser from starting on those systems, so this problem was hidden behind the issue of the browser not starting at all. After #31646 was fixed in the 2nd alpha, the browser could start again on those systems, but we probably did not test an update from the last esr60 to the 2nd esr68 alpha.

Note: See TracTickets for help on using tickets.