1421812 - startup crash, and crashreporter fails with debian and AppArmor

Status: RESOLVED WORKSFORME

(Thunderbird :: General, defect)

Description

[Jeff Lehrkamp]

Attachment: thunderbirdoutput

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0
Build ID: 20171114221957

Steps to reproduce:

Crashes on Startup consistently.  Running on debian buster linux.


Actual results:

Fails to start then crashreport fails also.  Attached file shows output from terminal when starting.  Includes dump info.


Expected results:

thunderbird starts.

Comment 1

[Jeff Lehrkamp]

Additional note using thunderbird with lightning.  I also use ice-owl and google-calendar-provider, but have purged and reinstalled the thunderbird and lightning without those packages and the exception still occurs.  Have also removed the .thunderbird and .iceowl folders and restarted to see if it was an issue with old data.  the crash still occurs.

Comment 3

[Wayne Mery (:wsmwk)]

Unfortunately the stack does not have Thunderbird symbols, so there is not much value for us.
One of the more common crashes on linux is bug 1347008

Does problem happen in safe mode?  https://support.mozilla.org/en-US/kb/safe-mode-thunderbird

Comment 4

[Jeff Lehrkamp]

Tried to run with thunderbird -safe-mode.  same crash occurs.  How would I get thunderbird symbols?

Comment 5

[Wayne Mery (:wsmwk)]

https://developer.mozilla.org/en-US/docs/Mozilla/How_to_get_a_stacktrace_for_a_bug_report#Alternative_ways_to_get_a_stacktrace

Comment 6

[denyasis]

Attachment: gdb.txt

thunderbird run with debug symbols

Comment 7

[denyasis]

Attachment: debian.txt

Debian reportbug output

Comment 8

[denyasis]

Hello;

I can confirm this bug in my system. I have added GDB.txt with debug symbols for Thunderbird as well as the output of reportbug for Thunderbird. I'm using SparkyLinux (follows Debian testing - Everything is up-to-date as of an hour ago).

Reinstalling and safe mode do not seem to work. If there is any other info I can provide, please let me know

Comment 9

[Wayne Mery (:wsmwk)]

Matti, does anything in stack stand out?

Comment 10

[denyasis]

Hello - I found the source of the crash in my case. 

Apparently Debian 9 testing had updated its apparmor profiles. They were incorrect for Thunderbird. Thunderbird was crashing because Apparmor was blocking access to a PCI device on my system. The bug reporter was crashing as apparmor was blocking access to /dev/tty. 

I tried editing the profile to allow read/write access to those devices as Thunderbird requested. I was able to get the /dev/tty sorted out but not the PCI device. I ended up disabling the profile for Thunderbird and it worked. 

This appears to be an Apparmor issue, specifically with the stock profile installed by debian. 

Thank you for your time.

Comment 11

[Matthias Versen [:Matti]]

Do you have the same issue Jeff or is your crash not related to the issue that denyasis reported ?

Comment 12

[Jeff Lehrkamp]

Not sure of the cause, I had not had a chance to do additional research on the issue.  I had been away and was accessing gmail via the web.  I will do some more research as soon as I am able.

Comment 13

[Carsten Schoenert]

The crashreporter for Thunderbird in Debian is disabled again starting with version 1:52.5.0-1~ like also the AppArmor profile so I assume the issue isn't visible in recent version from Debian unstable. The crashreporter needs for sure some tuning in the AppArmor profile.

But as I haven't enough time to figure out how the symbol collection could be done in a reliable and easy way (it's really tedious to fight with the build environment for getting this!) people who wants to improve the apparmor profile needs to enable the crashreporter by themselves. So right now the crashreporter is just useless in Debian due the not existing symbol information.

If the symbol collecting binaries could be build without adding a half tone of files from some unit testing and some more easy callable make targets this would helps a lot to also provide also symbol files from Debian builds. Please note that Debian packages (for the Debian main repository) needs to respect the Debian Free Software Guidelines and thus makes it hard to not include files in the sources that are not full DFSG compatible like a lot of files in the various tests from firefox source. Right now we just exclude them while preparing a source tarball to get the Thunderbird packages accepted in the repository.

Back to topic, I expect the reported issue isn't existing any more in recent package versions on Debian based systems.

Comment 14

[Jeff Lehrkamp]

Sorry for the delay getting back.  I have not yet done anymore research on the cause, but can tell you that the thunderbird app is not yet working.

Comment 15

[Wayne Mery (:wsmwk)]

(In reply to Carsten Schoenert from comment #13)
> The crashreporter for Thunderbird in Debian is disabled again starting with
> version 1:52.5.0-1~ like also the AppArmor profile so I assume the issue
> isn't visible in recent version from Debian unstable. The crashreporter
> needs for sure some tuning in the AppArmor profile.
> ...
> If the symbol collecting binaries could be build without adding a half tone
> of files from some unit testing and some more easy callable make targets
> this would helps a lot to also provide also symbol files from Debian builds.
> Please note that Debian packages (for the Debian main repository) needs to
> respect the Debian Free Software Guidelines and thus makes it hard to not
> include files in the sources that are not full DFSG compatible like a lot of
> files in the various tests from firefox source. Right now we just exclude
> them while preparing a source tarball to get the Thunderbird packages
> accepted in the repository.
> 
> Back to topic, I expect the reported issue isn't existing any more in recent
> package versions on Debian based systems.

Are there other debian bug reports which help these areas?
Are there bugs filed for ways we might help on the Thunderbird end?

Comment 16

[Carsten Schoenert]

(In reply to Wayne Mery (:wsmwk) from comment #15)
> Are there other debian bug reports which help these areas?

I'm not sure what you mean here? We have some bug reports regarding the Crash reporter.
https://bugs.debian.org/858919
https://bugs.debian.org/860906

> Are there bugs filed for ways we might help on the Thunderbird end?

Not as far I know.
I tried to work on collecting the symbols for the crash report some months ago. As I remember correctly the tools for preparing the symbol data are placed in mozilla/google-breakpad and need some extra call to get build. I searched my old files and folders about this and I used this make target (taken from Mike's Firefox build) while I tried to get the symbols in place. CURDIR is a variable that points to root of the source we want to build, aka the root of the extracted source.

> symbol:
> 	mkdir -p mozilla/google-breakpad
> 	MOZ_OBJDIR=build-breakpad cd mozilla/google-breakpad; \
> 		echo 'mk_add_options MOZ_OBJDIR=$(CURDIR)/mozilla/google-breakpad' >> mozconfig; \
> 		export MOZCONFIG=$(CURDIR)/mozilla/google-breakpad/mozconfig; \
> 		$(CURDIR)/mozilla/mach configure; \
> 		$(CURDIR)/mozilla/mach build pre-export export

But this wasn't working because some files from removed folders or individual removed files are missed. I would need to exclude the missed files from our repacking chain to get this working. I stopped here due lack of free time for doing this. Re adding file for file is time consuming because I'd need to do a lot of various steps again and again until the build is successful. If the build of the binaries wouldn't some JS files from some unit test this would be much easier.

If there would be a dedicated make target by Mozilla TB upstream to create the needed files would be helpful. But I need to dig into the whole thing again to describe more precise whats needed. Unfortunately I wont have time for this in the next weeks. Thanks to Rust and Cargo the build of TB is now again a quite long run as ccache isn't useful any more.

Comment 17

[Wayne Mery (:wsmwk)]

Tom, any helpful ideas to help with build or symbol issues for comment 16?

Comment 18

[Tom Prince [:tomprince]]

My only suggestion is to try switching to an m-c as topdir build. I don't really know anything about symbol generation, but lots of code in m-c isn't written to handle c-c as the topdir.

Comment 19

[Wayne Mery (:wsmwk)]

Jeff, has the advice thus far helped??

Comment 20

[Wayne Mery (:wsmwk)]

Jeff writes... working correctly now.  fixed with updates from debian.