Segfault after start on ARM

[CrazyFrog]

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?)

[x190]

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

[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?

[x190]

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

[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.

[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?

[mike.dld]

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

[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.

[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.