Opened 4 years ago
Closed 4 years ago
#16773 closed defect (duplicate)
Tumblr crashes TBB 5 for Linux x64
Reported by: | register4account | Owned by: | tbb-team |
---|---|---|---|
Priority: | Medium | Milestone: | |
Component: | Applications/Tor Browser | Version: | |
Severity: | Keywords: | tbb-crash | |
Cc: | Actual Points: | ||
Parent ID: | Points: | ||
Reviewer: | Sponsor: |
Description
After logged into tumblr, infinite scrolling down causes TBB 5 for Linux x64 to crash after about 2-3 pages.
Child Tickets
Change History (6)
comment:1 Changed 4 years ago by
comment:2 Changed 4 years ago by
Oh, you will need to download and copy the debug symbols into the right place:
https://trac.torproject.org/projects/tor/wiki/doc/TorBrowser/Hacking#UsingDebugSymbols
comment:3 Changed 4 years ago by
Component: | - Select a component → Tor Browser |
---|---|
Keywords: | tbb-crash added |
Owner: | set to tbb-team |
comment:4 Changed 4 years ago by
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `./firefox --class Tor Browser -profile TorBrowser/Data/Browser/profile.default'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00007f16d28cb79b in raise (sig=11) at ../nptl/sysdeps/unix/sysv/linux/pt-raise.c:37
37 ../nptl/sysdeps/unix/sysv/linux/pt-raise.c: No such file or directory.
(gdb) backtrace
#0 0x00007f16d28cb79b in raise (sig=11) at ../nptl/sysdeps/unix/sysv/linux/pt-raise.c:37
#1 0x00007f16cedb3ae2 in nsProfileLock::FatalSignalHandler (signo=11, info=0x7ffd50f88670,
context=0x7ffd50f88540)
at /home/ubuntu/build/tor-browser/profile/dirserviceprovider/nsProfileLock.cpp:180
#2 <signal handler called>
#3 nsACString_internal::Equals (this=0x20, aStr=...)
at /home/ubuntu/build/tor-browser/xpcom/string/nsTSubstring.cpp:702
#4 0x00007f16ce0fd291 in operator== (aRhs=..., aLhs=...)
at ../../dist/include/nsTSubstring.h:1159
#5 nsHostObjectProtocolHandler::RemoveDataEntry (aUri=..., aIsolationKey=...)
at /home/ubuntu/build/tor-browser/dom/base/nsHostObjectProtocolHandler.cpp:354
#6 0x00007f16ce0ecb7a in nsDocument::~nsDocument (this=0x7f16aa11b000,
in_chrg=<optimized out>) at /home/ubuntu/build/tor-browser/dom/base/nsDocument.cpp:1785
#7 0x00007f16ce6cfb65 in nsHTMLDocument::~nsHTMLDocument (this=0x7f16aa11b000,
in_chrg=<optimized out>)
at /home/ubuntu/build/tor-browser/dom/html/nsHTMLDocument.cpp:201
#8 0x00007f16cda81527 in SnowWhiteKiller::~SnowWhiteKiller (this=0x7ffd50f88c08,
in_chrg=<optimized out>)
at /home/ubuntu/build/tor-browser/xpcom/base/nsCycleCollector.cpp:2664
#9 0x00007f16cda7c1a1 in nsCycleCollector::FreeSnowWhite (this=0x7f16c52e4000,
aUntilNoSWInPurpleBuffer=aUntilNoSWInPurpleBuffer@entry=false)
at /home/ubuntu/build/tor-browser/xpcom/base/nsCycleCollector.cpp:2825
#10 0x00007f16cda7c425 in nsCycleCollector_doDeferredDeletion ()
at /home/ubuntu/build/tor-browser/xpcom/base/nsCycleCollector.cpp:4210
#11 0x00007f16cde2b6d7 in AsyncFreeSnowWhite::Run (this=0x7f16bd182aa0)
at /home/ubuntu/build/tor-browser/js/xpconnect/src/XPCJSRuntime.cpp:227
comment:5 Changed 4 years ago by
#5 nsHostObjectProtocolHandler::RemoveDataEntry (aUri=..., aIsolationKey=...) at /home/ubuntu/build/tor-browser/dom/base/nsHostObjectProtocolHandler.cpp:354 #6 0x00007f16ce0ecb7a in nsDocument::~nsDocument (this=0x7f16aa11b000, in_chrg=<optimized out>) at /home/ubuntu/build/tor-browser/dom/base/nsDocument.cpp:1785
https://trac.torproject.org/projects/tor/ticket/16771#comment:7
Looks like mikeperry was right in suspecting it was a dup.
comment:6 Changed 4 years ago by
Resolution: | → duplicate |
---|---|
Status: | new → closed |
Yes, this is a dup of #16771, and we should have a fix for that shortly (in fact we already have a patch at https://github.com/arthuredelstein/tor-browser/commit/16771 if you feel like trying to follow the other sections of the hacking document to build it).
Either way, thanks a lot for the backtrace to confirm it, register4account. Much appreciated!
A Linux user, eh? I suspect this is a dup of #16771, but if you're motivated, you could confirm it/provide a gdb backtrace:
https://trac.torproject.org/projects/tor/wiki/doc/TorBrowser/Hacking#Usinggdb
Probably the core file approach is easiest:
https://trac.torproject.org/projects/tor/wiki/doc/TorBrowser/Hacking#Generatinganddebuggingcorefiles
From there, the output of the command 'backtrace' is sufficient. We should only need the top 10 entries of the backtrace (from #0 to #10).