Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#4646 closed Bug (fixed)

Transmission-daemon crashes with SEGFAULT in libevent

Reported by: nrwiersma Owned by: jordan
Priority: Normal Milestone: 2.50
Component: Mac Client Version: 2.42
Severity: Normal Keywords:
Cc:

Description

Hi,

I get a wired crash from transmission-daemon 2.42 with a segfault in libevent-2.0-5 2.0.12. I am running Ubuntu server.

Attachments (1)

gdb-output.txt (9.0 KB) - added by nrwiersma 7 years ago.

Download all attachments as: .zip

Change History (18)

Changed 7 years ago by nrwiersma

comment:1 Changed 7 years ago by jordan

Thank you for taking the time to report this bug and helping to make Transmission better. Please answer these questions:

  • Is this reproducible?
  • If so, what specific steps should we take to recreate this bug?

This will help us to find and resolve the problem.

comment:2 Changed 7 years ago by nrwiersma

Hi,

It is completely random. Sometimes it will run for days with no problem, sometimes it will crash every hour. Sorry... I know this makes it way more difficult to find.

comment:4 Changed 7 years ago by stressinduktion

libevent has patched this particular problem: <https://github.com/libevent/libevent/commit/bec50680a31834619e66cb8b97edd6d5b5f15701>

Please check if the patch above fixes the problem for you.

comment:5 Changed 7 years ago by x190

I like the looks of this one!! --Jordan?

comment:6 follow-up: Changed 7 years ago by jordan

yes, x190?

comment:7 in reply to: ↑ 6 ; follow-up: Changed 7 years ago by x190

Replying to jordan:

yes, x190?

comment:4 should fix a number of extant crash report tickets and forum reports. I anxiously await the news of a revision that incorporates this patch.

comment:8 Changed 7 years ago by stressinduktion

@x190: a possible workaround until a new version is released, is to switch to a different name server. my problem was caused by a name server (a mikrotik one), which sends all responses to queries back in lowercase. this defeats 0x20 hardening which libevent applies. As a result the answers are considered as spoofed and won't be processed (but there was a bug in this logic; see comment from the libevent commit).

comment:9 follow-up: Changed 7 years ago by x190

stressinduktion: Thanks for bringing this libevent/evdns.c commit to our attention. What is a reliable nameserver address that I can suggest to users getting this crash in reply_handle()?

EDIT: It's okay--see below. :-)

Last edited 7 years ago by x190 (previous) (diff)

comment:10 in reply to: ↑ 7 Changed 7 years ago by jordan

Replying to x190:

Replying to jordan:

yes, x190?

comment:4 should fix a number of extant crash report tickets and forum reports. I anxiously await the news of a revision that incorporates this patch.

third-party/libevent/ automatically pulls from the upstream repository, so this doesn't require (and, really, doesn't even allow :) manual intervention on my part.

After doing an "svn up" and checking, I can confirm that the nightly builds already have this evdns fix.

comment:11 Changed 7 years ago by jordan

  • Component changed from Daemon to Mac Client
  • Milestone changed from None Set to 2.50
  • Owner set to jordan

This is a little tricky... 2.50 is already "out" in tarball form in order to meet the Fedora & Ubuntu Feature Freeze deadlines, but the Mac version is not yet out because of localization issues.

For Mac users, I'm tempted to milestone this for 2.50 since it bundles its own libevent and therefore 2.50 Mac users will have this fix.

But...

For Linux users, I'm tempted to mark this as "invalid" since it's out of our hands and relies on what version of libevent gets bundled by the Linux distros.

So, what's The Right Thing for handling this ticket? There's probably not one... but I'm going to recategorize this ticket for the Mac build and milestone for 2.50.

If someone wants to file a sibling ticket for Linux s.t. I can properly close it as invalid, feel free ;)

comment:12 Changed 7 years ago by jordan

  • Resolution set to fixed
  • Status changed from new to closed

comment:13 Changed 7 years ago by jordan

Okay, that's the ticket out of the way. Linux/BSD users experiencing this bug have two choices: (1) they can go encourage their distros to upgrade libevent s.t. they get this fix, or (2) they can build their own local copies of a fresh version of libevent and compile Transmission with that....

comment:14 Changed 7 years ago by x190

So does Jenkins » 2.4x-mac (r13230) incorporate this commit?

comment:15 in reply to: ↑ 9 Changed 7 years ago by stressinduktion

Replying to x190:

stressinduktion: Thanks for bringing this libevent/evdns.c commit to our attention. What is a reliable nameserver address that I can suggest to users getting this crash in reply_handle()?

EDIT: It's okay--see below. :-)

Currently I only know about the mikrotik dns caches crashing transmission reliably. Mikrotik also received a notification about this bug and accepted it as a valid one. There is no ETA when this will get fixed. Even after this patch, you should check your nameserver, as hostnames won't resolve even after applying this patch. It could be, that none of the responses to your queries will be accepted as valid and the torrent won't start.

To check your nameserver, there is a simple tool in sample/dns-example in the libevent sources. A broken nameserver looks like this:

$ ./sample/dns-example -v google.com
INFO: Parsing resolv.conf file /etc/resolv.conf
INFO: Added nameserver 10.0.1.254:53
EVUTIL_AI_CANONNAME in example = 2
resolving (fwd) google.com...
INFO: Resolve requested for google.com
INFO: Setting timeout for request 0x8fda10
INFO: Removing timeout for request 0x8fda10
google.com: No answer (66)

comment:16 Changed 7 years ago by BorderBoetie

I see comment 13. I am using transmission on ubuntu. How do I go about doing (2)?

comment:17 Changed 7 years ago by x190

You might get more info by posting on the forum.

https://forum.transmissionbt.com/

Note: See TracTickets for help on using tickets.