Opened 13 years ago

Closed 12 years ago

#1992 closed Bug (fixed)

failed assertion `session->events != NULL'

Reported by: mtu Owned by: charles
Priority: High Milestone: 1.72
Component: Transmission Version: 1.52+
Severity: Critical Keywords:
Cc: vladykin@…, motto.uieoa@…, armen.abrahamian@…, mbone3000, nick@…, doekman@…

Description (last modified by charles)

I've seen this (or at least a similar) problem with various versions in various stages - apparently even in various parts of the code. I'm thorougly sick of it and will create tickets now. I can't use Transmission like this!

gdb output:

/Users/mitchell/Desktop/Transmission_1.5x/libtransmission/trevent.c:357: failed assertion `session->events != NULL'

Program received signal SIGABRT, Aborted.
0x96c971c6 in mach_msg_trap ()
(gdb) bt
#0  0x96c971c6 in mach_msg_trap ()
#1  0x96c9e9bc in mach_msg ()
#2  0x926860ae in CFRunLoopRunSpecific ()
#3  0x92686cd8 in CFRunLoopRunInMode ()
#4  0x908182c0 in RunCurrentEventLoopInMode ()
#5  0x908180d9 in ReceiveNextEventCommon ()
#6  0x90817f4d in BlockUntilNextEventMatchingListInMode ()
#7  0x95417d7d in _DPSNextEvent ()
#8  0x95417630 in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] ()
#9  0x9541066b in -[NSApplication run] ()
#10 0x953dd8a4 in NSApplicationMain ()
#11 0x00002e45 in ?? ()
#12 0x00002d9b in ?? ()
#13 0x00002cc9 in ?? ()

Doesn't seem to matter what torrent it is, what filesystem it's on (HFS+, CIFS, FAT32), etc ...

Apple detailed bug report of a hopefully similar crash (same conditions):

Process:         Transmission [72357]
Path:            /Applications/Transmission.app/Contents/MacOS/Transmission
Identifier:      org.m0k.transmission
Version:         1.52 (8222)
Code Type:       X86 (Native)
Parent Process:  launchd [161]

Date/Time:       2009-04-14 22:37:09.402 +0200
OS Version:      Mac OS X 10.5.6 (9G55)
Report Version:  6

Exception Type:  EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Crashed Thread:  2

Thread 0:
0   libSystem.B.dylib                 0x96c971c6 mach_msg_trap + 10
1   libSystem.B.dylib                 0x96c9e9bc mach_msg + 72
2   com.apple.CoreFoundation          0x926860ae CFRunLoopRunSpecific + 1790
3   com.apple.CoreFoundation          0x92686cd8 CFRunLoopRunInMode + 88
4   com.apple.HIToolbox               0x908182c0 RunCurrentEventLoopInMode + 283
5   com.apple.HIToolbox               0x908180d9 ReceiveNextEventCommon + 374
6   com.apple.HIToolbox               0x90817f4d BlockUntilNextEventMatchingListInMode + 106
7   com.apple.AppKit                  0x95417d7d _DPSNextEvent + 657
8   com.apple.AppKit                  0x95417630 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 128
9   com.apple.AppKit                  0x9541066b -[NSApplication run] + 795
10  com.apple.AppKit                  0x953dd8a4 NSApplicationMain + 574
11  org.m0k.transmission              0x00002e45 0x1000 + 7749
12  org.m0k.transmission              0x00002d9b 0x1000 + 7579
13  org.m0k.transmission              0x00002cc9 0x1000 + 7369

Thread 1:
0   libSystem.B.dylib                 0x96cc7906 kevent + 10
1   com.apple.Foundation              0x93e857ed -[NSThread main] + 45
2   com.apple.Foundation              0x93e85394 __NSThread__main__ + 308
3   libSystem.B.dylib                 0x96cc8095 _pthread_start + 321
4   libSystem.B.dylib                 0x96cc7f52 thread_start + 34

Thread 2 Crashed:
0   libSystem.B.dylib                 0x96d73136 __semwait_signal_nocancel + 10
1   libSystem.B.dylib                 0x96d6c013 usleep$NOCANCEL$UNIX2003 + 61
2   libSystem.B.dylib                 0x96d83685 abort + 85
3   org.m0k.transmission              0x00097104 0x1000 + 614660
4   org.m0k.transmission              0x0006e0c5 0x1000 + 446661
5   org.m0k.transmission              0x0005ac18 0x1000 + 367640
6   org.m0k.transmission              0x0008161e 0x1000 + 525854
7   org.m0k.transmission              0x00081b5d 0x1000 + 527197
8   libSystem.B.dylib                 0x96cc8095 _pthread_start + 321
9   libSystem.B.dylib                 0x96cc7f52 thread_start + 34

Thread 2 crashed with X86 Thread State (32-bit):
  eax: 0x0000003c  ebx: 0x96d72c88  ecx: 0xb01bfd4c  edx: 0x96d73136
  edi: 0x00873a00  esi: 0xb01bfda8  ebp: 0xb01bfd88  esp: 0xb01bfd4c
   ss: 0x0000001f  efl: 0x00000247  eip: 0x96d73136   cs: 0x00000007
   ds: 0x0000001f   es: 0x0000001f   fs: 0x0000001f   gs: 0x00000037
  cr2: 0xffe171dc

Attachments (1)

loop-until-death.patch (535 bytes) - added by wereHamster 12 years ago.
Not even runtime tested, side-effects unknown, use at your own risk

Download all attachments as: .zip

Change History (49)

comment:1 Changed 13 years ago by charles

  • Milestone changed from None Set to 1.60
  • Owner set to charles
  • Status changed from new to assigned

Ticket #1720 is a duplicate of this ticket.

Summary there: it's also happening on Solaris in the nightly builds, and started happening sometime during the 1.50 betas.

comment:2 Changed 13 years ago by charles

  • Description modified (diff)

comment:3 Changed 13 years ago by charles

mtu: are you in the process of exiting Transmission when this happens?

comment:4 Changed 13 years ago by mtu

charles: nope, basically starting/unpausing

comment:5 Changed 13 years ago by livings124

  • Summary changed from Transmission crashes after checking data on Mac OS X: failed assertion `session->events != NULL' to Transmission crashes after checking data: failed assertion `session->events != NULL'

comment:6 follow-up: Changed 13 years ago by charles

Is this easy to reproduce? I verify a lot of torrents but haven't hit this issue.

Can you run T in gdb and set a breakpoint for abort(), and attach a backtrace?

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

Replying to charles:

Is this easy to reproduce? I verify a lot of torrents but haven't hit this issue.

Can you run T in gdb and set a breakpoint for abort(), and attach a backtrace?

sure:

/Users/mitchell/Desktop/Transmission_1.5x/libtransmission/trevent.c:357: failed assertion `session->events != NULL' [Switching to process 5014 thread 0xba2f]

Breakpoint 1, 0x96d83634 in abort () (gdb) (gdb) bt #0 0x96d83634 in abort () #1 0x00097104 in ?? () #2 0x0006e0c5 in ?? () #3 0x0005ac18 in ?? () #4 0x0008161e in ?? () #5 0x00081b5d in ?? () #6 0x96cc8095 in _pthread_start () #7 0x96cc7f52 in thread_start () (gdb)

not very helpful. heh. :(

comment:8 in reply to: ↑ 7 ; follow-up: Changed 13 years ago by charles

Replying to mtu:

/Users/mitchell/Desktop/Transmission_1.5x/libtransmission/trevent.c:357: failed assertion `session->events != NULL' [Switching to process 5014 thread 0xba2f]

Breakpoint 1, 0x96d83634 in abort () (gdb) (gdb) bt #0 0x96d83634 in abort () #1 0x00097104 in ?? () #2 0x0006e0c5 in ?? () #3 0x0005ac18 in ?? () #4 0x0008161e in ?? () #5 0x00081b5d in ?? () #6 0x96cc8095 in _pthread_start () #7 0x96cc7f52 in thread_start () (gdb)

not very helpful. heh. :(

Was this one while shutting down too? And, which build was this crash in?

Also, how do I get it to crash except during shutdown?

comment:9 in reply to: ↑ 8 Changed 13 years ago by mtu

Replying to charles:

Replying to mtu:

/Users/mitchell/Desktop/Transmission_1.5x/libtransmission/trevent.c:357: failed assertion `session->events != NULL' [Switching to process 5014 thread 0xba2f]

Breakpoint 1, 0x96d83634 in abort () (gdb) (gdb) bt #0 0x96d83634 in abort () #1 0x00097104 in ?? () #2 0x0006e0c5 in ?? () #3 0x0005ac18 in ?? () #4 0x0008161e in ?? () #5 0x00081b5d in ?? () #6 0x96cc8095 in _pthread_start () #7 0x96cc7f52 in thread_start () (gdb)

not very helpful. heh. :(

Was this one while shutting down too? And, which build was this crash in?

non-shutdown with vanilla 1.52 mac

Also, how do I get it to crash except during shutdown?

no idea :(

comment:10 Changed 13 years ago by av

  • Cc vladykin@… added

Happens for me on OpenSolaris? with Transmission 1.52 compiled from sources with SunStudio? compilers. Assertion failure happens immediately after start, when Transmission GUI is not shown yet.

I've tracked this down to port_getn() failure in evport_dispatch():

	if ((res = port_getn(epdp->ed_port, pevtlist, EVENTS_PER_GETN, 
		    (unsigned int *) &nevents, ts_p)) == -1) {
		if (errno == EINTR || errno == EAGAIN) {
			evsignal_process(base);
			return (0);
		} else if (errno == ETIME) {
			if (nevents == 0)
				return (0);
		} else {
			event_warn("port_getn"); // troubles start
			return (-1);             // after getting here...
		}
	} else if (base->sig.evsignal_caught) {
		evsignal_process(base);
	}

After evport_dispatch() returns -1 the whole event dispatch thread terminates, and session->events is set to NULL. After this the first call to tr_runInEventThread() results in assertion failure.

I've worked this around by changing "return -1;" to "return 0;". After that Transmission works without visible problems.

comment:11 Changed 13 years ago by charles

av: what does the startup crash backtrace look like? I'm wondering, is this a libevent error that needs to be reported upstream, or is it a bootstrapping bug in Transmission?

comment:12 Changed 13 years ago by av

Here it is:

t@1 (l@1) terminated by signal ABRT (Abort)
0xfcfc22a5: _lwp_kill+0x0015:   jae      _lwp_kill+0x23 [ 0xfcfc22b3, .+0xe ]
Current function is tr_runInEventThread
  357       assert( session->events != NULL );
(dbx) where
current thread: t@1
  [1] _lwp_kill(0x1, 0x6, 0x80473d4, 0xfcfba9fa), at 0xfcfc22a5 
  [2] thr_kill(0x1, 0x6, 0x80473d4, 0xfcf6ab7e), at 0xfcfbaa1c 
  [3] raise(0x6, 0x0, 0x8047424, 0xfcf41ffa), at 0xfcf6ab8a 
  [4] abort(0x65737341, 0x6f697472, 0x6166206e, 0x64656c69, 0x6573203a, 0x6f697373, 0x653e2d6e, 0x746e6576, 0x3d212073, 0x4c554e20, 0x66202c4c, 0x20656c69, 0x76657274, 0x2e746e65, 0x6c202c63, 0x20656e69, 0x2c373533, 0x6e756620, 0x6f697463, 0x7274206e), at 0xfcf4201a 
  [5] _assert_c99(0x8124a40, 0x8124a58, 0x165, 0x8116b42, 0x0, 0x0), at 0xfcf42300 
=>[6] tr_runInEventThread(session = 0x821c6a8, func = 0x80c4f40 = &`transmission`torrent.c`checkAndStartImpl(void *vtor), user_data = 0x82bc398), line 357 in "trevent.c"
  [7] checkAndStartCB(tor = 0x82bc398), line 1116 in "torrent.c"
  [8] fireCheckDone(tor = 0x82bc398, verify_done_cb = 0x80c5050 = &`transmission`torrent.c`checkAndStartCB(tr_torrent *tor)), line 42 in "verify.c"
  [9] tr_verifyAdd(tor = 0x82bc398, verify_done_cb = 0x80c5050 = &`transmission`torrent.c`checkAndStartCB(tr_torrent *tor)), line 177 in "verify.c"
  [10] torrentStart(tor = 0x82bc398, reloadProgress = 0), line 1137 in "torrent.c"
  [11] torrentRealInit(session = 0x821c6a8, tor = 0x82bc398, ctor = 0x82b1108), line 594 in "torrent.c"
  [12] tr_torrentNew(session = 0x821c6a8, ctor = 0x82b1108, setmeError = (nil)), line 643 in "torrent.c"
  [13] tr_sessionLoadTorrents(session = 0x821c6a8, ctor = 0x82b1108, setmeCount = 0x80478cc), line 1004 in "session.c"
  [14] tr_core_load(self = 0x8169b88, forcePaused = 0), line 805 in "tr-core.c"
  [15] appsetup(wind = 0x821ad08, torrentFiles = (nil), cbdata = 0x814a318, forcepause = 0, isIconified = 0), line 596 in "main.c"
  [16] main(argc = 1, argv = 0x8047a20), line 452 in "main.c"

comment:13 Changed 13 years ago by charles

Very interesting....

I think if you rebuild Transmission after deleting the line in libtransmission/trevent.c that reads "event_set_log_callback( logFunc );" then libevent will dump error messages to the terminal. Could you try doing that and see what error it gives?

comment:14 Changed 13 years ago by av

$ gtk/transmission 
[warn] port_getn: Error 0
Assertion failed: session->events != NULL, file trevent.c, line 357, function tr_runInEventThread
Abort (core dumped)

comment:15 follow-up: Changed 12 years ago by charles

  • Description modified (diff)

This really ought to get fixed for 1.60, but I still can't see where the source of the problem is coming from.

comment:16 Changed 12 years ago by charles

  • Milestone changed from 1.60 to Sometime

comment:17 in reply to: ↑ 15 Changed 12 years ago by uieoa

  • Cc motto.uieoa@… added
  • Version changed from 1.52 to 1.52+

Replying to charles:

This really ought to get fixed for 1.60, but I still can't see where the source of the problem is coming from.

I have v 1.60, and Transmission crashes (Notice Assertion failed: (session->events != NULL), function tr_runInEventThread, file /Users/mitchell/Desktop/Transmission/libtransmission/trevent.c, line 357. ) on quit and pause/restart

I can provide crashlogs o use gdb, will it be helpfull?

Identifier:      org.m0k.transmission
Version:         1.60 (8308)
Code Type:       X86 (Native)
Parent Process:  launchd [188]

Date/Time:       2009-05-05 20:59:02.256 +0400
OS Version:      Mac OS X 10.5.6 (9G55)
Report Version:  6

Exception Type:  EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Crashed Thread:  0

comment:18 Changed 12 years ago by David Munch

I just wanted to chime in here. I just had this exact crash on Mac OS X 10.5.6, running 1.52 (8222 - Stable release). Transmission just randomly crashed, while i was doing nothing with it. It had been running consistently in the background for about an hour, before this happened.

comment:19 follow-up: Changed 12 years ago by charles

Is there anyone watching this ticket / experiencing this bug that could put in a debug message to see what the unhandled errno is in the libevent code that calls port_getn()?

comment:20 follow-up: Changed 12 years ago by charles

av: looks like the evport handler is Solaris-only, so you'll need to be the one to dig into that part of this ticket...

comment:21 in reply to: ↑ 19 ; follow-up: Changed 12 years ago by uieoa

Replying to charles:

Is there anyone watching this ticket / experiencing this bug that could put in a debug message to see what the unhandled errno is in the libevent code that calls port_getn()?

I can But Transmission for Mac OS X *not* use ./third-party/libevent/evport.c - the only file called port_getn()

Next idea to check?

comment:22 in reply to: ↑ 20 Changed 12 years ago by av

Replying to charles:

According to my previous comment, errno was 0

[warn] port_getn: Error 0

Checked again today - got 0 as well. Suspicious enough, isn't it?

I consulted errno man page and found that it works for multithreaded applications only if compiled with -mt option. So I recompiled Transmission with -mt and now it works!

Here is my configure command for Sun compilers:

./configure CC=c99 CXX=CC CFLAGS='-D__EXTENSIONS__ -mt' --enable-gtk --enable-cli --enable-daemon --enable-libnotify --disable-wx

comment:23 follow-up: Changed 12 years ago by charles

av: it looks like -mt is a Sun CC thing; is that correct? I was thinking of adding -mt when AC_CANONICAL_HOST is solaris*), but maybe this isn't such a great idea if it'll break for solaris users compiling with gcc...

comment:24 in reply to: ↑ 21 Changed 12 years ago by charles

Replying to uieoa:

But Transmission for Mac OS X *not* use ./third-party/libevent/evport.c - the only file called port_getn()

Next idea to check?

Looks like it uses kqueue on the mac, so next I'd try putting warnings/messages in kq_dispatch().

comment:25 in reply to: ↑ 23 Changed 12 years ago by av

Replying to charles:

av: it looks like -mt is a Sun CC thing; is that correct? I was thinking of adding -mt when AC_CANONICAL_HOST is solaris*), but maybe this isn't such a great idea if it'll break for solaris users compiling with gcc...

Corresponding flag for gcc is -threads. I've just built Transmission with gcc 3.4.3 and -threads. It's working like a charm.

comment:26 Changed 12 years ago by Armen52

  • Cc armen.abrahamian@… added

comment:27 Changed 12 years ago by icookie

This has been bugging me for ages.. on 1.50, 1.51, 1.52 and 1.60.... Someone please fix it soon, it's the only decent torrent client for Mac.

comment:28 Changed 12 years ago by charles

  • Summary changed from Transmission crashes after checking data: failed assertion `session->events != NULL' to failed assertion `session->events != NULL'

comment:29 Changed 12 years ago by mbone3000

  • Cc mbone3000 added

I also have this crash quite frequently (upon adding a new torrent, or pausing restarting a torrent) i do not know whether my crash logs will be helpful, but here are a couple:

http://transmission.pastebin.com/m150bd002

http://transmission.pastebin.com/m13539b6e

Mac OS X - V 10.5.6 MacBook? - Processor 1.25 GHz PowerPC G4

i love Transmission, but this is very frustrating and has happened over muttiple versions. Currently I'm running Transmission 1.60 (8308) and for the moment no crashes.

comment:30 Changed 12 years ago by mtu

... and here I was wondering whether I was the only one with this problem ...

comment:31 Changed 12 years ago by peelman

  • Cc nick@… added

@mtu

Nope, I too have been experiencing this in the most recent builds. here's what i'm seeing in Syslog (not much):

May 17 16:09:26 mizar [0x0-0x2ce2ce].org.m0k.transmission[40830]: Assertion failed: (tv->tv_usec >= 0), function timeout_next, file /var/tmp/pea/svn.transmissionbt.com/trunk/third-party/libevent/event.c, line 875. May 17 16:09:28 mizar ReportCrash?[41400]: Formulating crash report for process Transmission[40830] May 17 16:09:30 mizar ReportCrash?[41400]: Saved crashreport to /Users/peelman/Library/Logs/CrashReporter/Transmission_2009-05-17-160927_Mizar.crash using uid: 502 gid: 20, euid: 502 egid: 20 May 17 16:09:33 mizar ReportCrash?[41400]: Failed to relaunch /Users/peelman/Applications/Transmission.app/Contents/MacOS/Transmission - LSOpenApplication returned OSStatus: -600!

Mac Pro (Early 2008), 10.5.7, Transmission 1.61 (8418).

I can't remember if the crash existed pre-10.5.7 or not.

comment:32 Changed 12 years ago by mtu

@cc: it did. I moved to 10.5 from Tiger (even a fresh install) trying to escape it.

comment:33 Changed 12 years ago by safonas

Confirm adding "-threads" to gcc and "-mt" to SunStudio? fixes problem on OpenSolaris? svn_b111a. Transmission 1.61 (8385)

comment:34 Changed 12 years ago by peelman

I have created a launchd item to keep Transmission running through all the crashes...though at this point by the time it gets done "checking existing data" its time for a new crash :\

comment:35 Changed 12 years ago by peelman

I am seeing the crash like clockwork, every twenty minutes, almost on the nose.

Screenshot of Crash Reports

Poking around in Instruments, I didn't see a memory leak or anything obvious. Any ideas what could cause something so cyclical?

Changed 12 years ago by wereHamster

Not even runtime tested, side-effects unknown, use at your own risk

comment:36 Changed 12 years ago by charles

There is a possible fix for this now in r8467.

Since we're on the cusp of a 1.54 and 1.62 release, it would be very nice if some of the people cc'ed to this ticket could give some quick feedback on this...

comment:37 Changed 12 years ago by houst0n

I just downloaded latest svn snapshot and built it on 5.11 with gcc. Worked well.

Going to head over to the build farm and give it a try on S10 with sunstudio next.

As far as I can see though, it's not died from any of those asserts.

Will let you know how I get on with ss12.

comment:38 Changed 12 years ago by houst0n

I've now built this on the following hosts:

SunOS 5.11 w/ GCC 3.x SunOS 5.10 w/ SS11

Both of the builds are working fine.

Thank you charles!

-houst0n

comment:39 follow-up: Changed 12 years ago by peelman

Updated to the latest build before the weekend and the problem seems to have went away...I have no new crash reports since Friday, May 22nd. Looks like you've got it.

comment:40 in reply to: ↑ 39 Changed 12 years ago by charles

Replying to peelman:

Updated to the latest build before the weekend and the problem seems to have went away...I have no new crash reports since Friday, May 22nd. Looks like you've got it.

Well we haven't changed anything... but apparently it was an upstream bug in libevent, so maybe they've caught it. I'll take a look at their changelog and see if anything sticks out.

comment:41 Changed 12 years ago by charles

Ticket #2140 has been marked as a duplicate of this bug.

comment:42 Changed 12 years ago by doekman

  • Cc doekman@… added

comment:43 Changed 12 years ago by houst0n

Hmm, looks like I spoke too soon.

I've tested on the following platforms with 1.71:

Solaris 8/x86 - SunStudio? 11 Solaris 10/x86 - SunStudio? 12, SSXE 09/03 and GCC 3.x

All of them SIGABRT like so:

(insomnia:~) houst0n > transmission Assertion failed: eh->die, file trevent.c, line 239, function libeventThreadFunc Abort (core dumped)

I'll try building against the 2.x version of libevent next.

comment:44 Changed 12 years ago by houst0n

Hmm, no such luck. 2.0.x of libevent will require significant modification to compile on Solaris.

Just for the sake of it though, I copied the libevent folder from a 1.40 build I have on the build farm (from the work directory for the package we have in the repo at the moment) and rebuilt. Compiled without issues, however:

(insomnia:~/dump) houst0n > transmission Assertion failed: eh->die, file trevent.c, line 239 Abort (core dumped)

Same stuff.

comment:45 Changed 12 years ago by houst0n

Charles, if you need access to an OpenSolaris? box I can hook you up; just msg me on freenode, my nick is houst0n.

comment:46 Changed 12 years ago by houst0n

Doh. My mistake, when building 1.71 it appears -mt escaped from my CFLAGS.

Built/working.

comment:47 Changed 12 years ago by charles

This is believed fixed in 1.72. I'd be interested in getting feedback on this from users who were experiencing this bug in earlier versions...

comment:48 Changed 12 years ago by livings124

  • Milestone changed from Sometime to 1.72
  • Resolution set to fixed
  • Status changed from assigned to closed

There hasn't been a single report of this since 1.72.

Note: See TracTickets for help on using tickets.