Opened 3 years ago

Closed 3 years ago

Last modified 3 years ago

#20979 closed defect (fixed)

runtime/cgo: pthread_create failed: Resource temporarily unavailable

Reported by: vladimiroff Owned by: yawning
Priority: Medium Milestone:
Component: Archived/Tor Browser Sandbox Version:
Severity: Normal Keywords: pthread_create failed
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

It happens on Fedora 25 x86-64 (4.8.13-300.fc25.x86_64)
Go: 1.7.4
bubblewrap: 0.1.4-5
libseccomp: 2.3.1-1
libseccomp-devel: 2.3.1-1
libseccomp-static: 2.3.1-1

Once compiled the sanboxed-tor-browser starts and open dialog for choosing
channel and locale. No matter what is being chosen, it crashes with
runtime/cgo: pthread_create failed: Resource temporarily unavailable,
right after checking for available downloads. (see attached dump).

Also, once crashed it doesn't clean up /run/user/1000/sandboxed-tor-browser
and it has to be removed manually in order to be started again.

Child Tickets

Attachments (2)

panic.txt (13.2 KB) - added by vladimiroff 3 years ago.
panic output
panic2.txt (10.6 KB) - added by yawning 3 years ago.

Download all attachments as: .zip

Change History (9)

Changed 3 years ago by vladimiroff

Attachment: panic.txt added

panic output

comment:1 Changed 3 years ago by qbi

I see the same with a Debian unstable system (golang-go 2:1.7~4, bubblewrap 0.1.4-2, libseccomp2 2.3.1-2).

comment:2 Changed 3 years ago by yawning

Looking at the trace, it's crashing in the pure Go DNS resolver trying to fetch the list of bundles to download. Since I can't reproduce this, I'll need someone to paste the crash output (like the panic.txt) with debugging enabled.

{{
export GOTRACEBACK=system
export GODEBUG=netdns=2
./bin/sandboxed-tor-browser
}}

Could also try forcing the cgo resolver with export GODEBUG=netdns=cgo+2, but the non-cgo version should be the more robust one...

Changed 3 years ago by yawning

Attachment: panic2.txt added

comment:3 Changed 3 years ago by yawning

Another panic that someone uploaded to pastebin and wrote a blog comment about. This time it's elsewhere so I guess the DNS resolver isn't the root cause. If this turns out to be something like "you were dumb enough to think that cgo bindings to gtk will actually work", I'll be kind of sad.

comment:4 Changed 3 years ago by yawning

One other thing this could be is another rlimit() problem, since running out of VmStk can cause pthread_create() to fail. If this is the case then db42366aabfd4ed975e34197a09a4a6fff4aa322, that I committed yesterday will fix that. I really need to like, be able to reproduce this. :(

comment:5 Changed 3 years ago by yawning

Setting RLIMIT_NPROC to 512 might also be the culprit here, if people are doing lots of things on their systems, the limit I imposed would be overwhelmed near immediately.

comment:6 Changed 3 years ago by yawning

Resolution: fixed
Status: newclosed

https://gitweb.torproject.org/tor-browser/sandboxed-tor-browser.git/commit/?id=c02de8ea005fb858bdbaf79dd36ea93b1014521b

Since I can't get a hold of anyone that had the symptoms, I will assume this was the problem.

comment:7 Changed 3 years ago by yawning

Just to follow up on this, a user on the blog confirmed that it is fixed on master, and was gracious enough to show ps output exceeding the old 512 combined process/lwp limit. Further issues in this area should be handled as new bugs.

Note: See TracTickets for help on using tickets.