Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#5782 closed Bug (fixed)

Segfault after start on ARM

Reported by: CrazyFrog Owned by:
Priority: Normal Milestone: None Set
Component: Transmission Version: 2.84+
Severity: Normal Keywords:
Cc:

Description

Since yesterday transmission started segfaulting just after start. I tried update in to the latest svn version but it's still failing...

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x40fd7450 (LWP 15063)]
0x0004b3a0 in countArray (b=0x13b722) at bitfield.c:51
51          ret += trueBitCount[b->bits[i]];
(gdb) bt
#0  0x0004b3a0 in countArray (b=0x13b722) at bitfield.c:51
#1  0x0004bda4 in tr_bitfieldRebuildTrueCount (b=0x13b722) at bitfield.c:265
#2  0x0004c194 in tr_bitfieldSetRaw (b=0x13b722, bits=0xe5f10, byte_count=574, bounded=false) at bitfield.c:346
#3  0x0007003c in readBtMessage (msgs=0x13b6f8, inbuf=0xd55f0, inlen=790) at peer-msgs.c:1556
#4  0x0007116c in canRead (io=0xdb650, vmsgs=0x13b6f8, piece=0x40fd6a8c) at peer-msgs.c:1779
#5  0x0005a3c0 in canReadWrapper (io=0xdb650) at peer-io.c:203
#6  0x0005a75c in event_read_cb (fd=24, event=2, vio=0xdb650) at peer-io.c:284
#7  0x4004b1ac in event_base_loop () from /usr/lib/libevent-2.0.so.5
#8  0x0002ea30 in libeventThreadFunc (veh=0xc91d0) at trevent.c:246
#9  0x0000fed4 in ThreadFunc (_t=0xc9ab8) at platform.c:105
#10 0x40335910 in start_thread () from /lib/libpthread.so.0
#11 0x404188dc in clone () from /lib/libc.so.6
#12 0x404188dc in clone () from /lib/libc.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Change History (9)

comment:1 Changed 7 years ago by x190

How can this be reproduced? Is it caused only by a certain torrent? Are webseeds involved? Recent Coronal Mass Ejections (X1.6)?

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

comment:2 Changed 7 years ago by cfpp2p

In addition to x190's inquiries, what changed on your system since yesterday? What is your version of libevent and when was it updated?

comment:3 Changed 7 years ago by x190

Also, go to your .config folder and delete or remove the .resume file(s) and "Verify Local Data" and see if that helps.

comment:4 follow-ups: Changed 7 years ago by CrazyFrog

Well, by parts...

  • The only change in the system was transmission itself. It's an Iomega NAS running debian and it's a bit old.
  • It can be related to a torrent file, I "solved" the problem removing all data and config files doing a fresh checkout from svn and building it again. Now it starts but, after a few time it fails with another problem (transmission-daemon: peer-msgs.c:708: tr_peerMsgsCalculateActive: Assertion `!tr_peerIsSeed (&msgs->peer)' failed.).
  • libevent-2.0.21-stable built from source. I can update it if you think it's better.
  • Removing all data and config files "solved" the problem. It was stable for a few days just after start crashing again.

comment:5 in reply to: ↑ 4 Changed 7 years ago by cfpp2p

Replying to CrazyFrog:

  • It can be related to a torrent file, I "solved" the problem removing all data and config files doing a fresh checkout from svn and building it again. Now it starts but, after a few time it fails with another problem (transmission-daemon: peer-msgs.c:708: tr_peerMsgsCalculateActive: Assertion `!tr_peerIsSeed (&msgs->peer)' failed.).

#5762 and #5505

since it looks like you are using current trunk then r14319 doesn't fix this crash which I think is related to webseeds. Is the offending torrent with webseed?

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

comment:6 Changed 7 years ago by mike.dld

Please do bt full (or even better, thread apply all bt full) next time you debug.

comment:7 in reply to: ↑ 4 Changed 7 years ago by x190

Replying to CrazyFrog:

Well, by parts...

  • The only change in the system was transmission itself. It's an Iomega NAS running debian and it's a bit old.
  • It can be related to a torrent file, I "solved" the problem removing all data and config files doing a fresh checkout from svn and building it again. Now it starts but, after a few time it fails with another problem (transmission-daemon: peer-msgs.c:708: tr_peerMsgsCalculateActive: Assertion `!tr_peerIsSeed (&msgs->peer)' failed.).
  • libevent-2.0.21-stable built from source. I can update it if you think it's better.
  • Removing all data and config files "solved" the problem. It was stable for a few days just after start crashing again.

Since the original problem (possibly a corrupt .resume file)* has been "solved" this ticket can be closed. For a somewhat hacky solution for the "tr_peerMsgsCalculateActive: Assertion `!tr_peerIsSeed (&msgs->peer)' failed" issue, please see: https://trac.transmissionbt.com/ticket/5505#comment:15

*EDIT: Quoting CF:

Well, by parts...

  • The only change in the system was transmission itself. It's an Iomega NAS running debian and it's a bit old.

There has been bitfield updates since debian's v2.52, including a memory allocation update, so that may also have been a factor.

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

comment:8 Changed 7 years ago by x190

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

comment:9 Changed 7 years ago by mike.dld

It is not that clear for me that original issue has indeed been fixed. @CrazyFrog, could you please confirm?

Also, judging from the stack (too bad only from a single thread) I don't see what the issue was exactly. It looks like Transmission has got a bitfield for particular peer (not from .resume file for sure) and tried saving it, byte_count argument looks sane. Something must have happened in another thread to b->bits and/or b->alloc_count.

Note: See TracTickets for help on using tickets.