#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 8 years ago by x190
comment:2 Changed 8 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 8 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: ↓ 5 ↓ 7 Changed 8 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 8 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.).
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?
comment:6 Changed 8 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 8 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.
comment:8 Changed 8 years ago by x190
- Resolution set to fixed
- Status changed from new to closed
comment:9 Changed 8 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.
How can this be reproduced? Is it caused only by a certain torrent? Are webseeds involved? Recent Coronal Mass Ejections (X1.6)?