v4.0 upgrade: assertion failed: bit_count_ == 0 || n <= bit_count_

[rpatterson]

What is the issue?

Using the linuxserver/transmission container image at time of writing this, everything seems to work fine until I add the ./transmission/config/:/config/ volume containing all the real torrent data for the set of running torrents I have working currently under v3.0. With that volume added starting the v4.0 container repeats the following error over and over until the container is killed for being unhealthy:

...
transmission  | [custom-init] No custom files found, skipping...                                                                                                           
transmission  | assertion failed: bit_count_ == 0 || n <= bit_count_ (/home/buildozer/aports/community/transmission/src/transmission-4.0.0/libtransmission/bitfield.cc:233)
transmission  | ./run: line 6:   161 Aborted                 s6-notifyoncheck -d -n 300 -w 1000 -c "nc -z localhost 9091" s6-setuidgid abc /usr/bin/transmission-daemon -g 
/config -c /watch -f                                                                                                                                                       
...

Which application of Transmission?

transmission-daemon

Which version of Transmission?

https://hub.docker.com/layers/linuxserver/transmission/amd64-4.0.0-r5-ls154/images/sha256-bdbbd04d1cbd96aa6a3afe8e215d400d73293dee735a310da9d78aed63548ce8?context=explore

[rpatterson]

While looking for any existing issues or other context for this error message, I found #2727 which mentions the same assertion, but that thread is quite long and most of it is greek to me. I thought I'd mention anyways it in case it helps.

[boomboxnation]

Same error. But transmission4-gtk 4.0.0-2 and whatever version immediately before that did the same. From AUR

After having seen rpatterson's "fix" of adding the config directory, I moved my transmission3 config directory out of the way and transmission4-gtk starts up fine, just without my current torrents/settings of course. I shut down t4, moved my original config directory back in place and receive the bitfield error again.

$ transmission-gtk
assertion failed: bit_count_ == 0 || n <= bit_count_ (/home/USER/.cache/yay/transmission4/src/transmission-4.0.0/libtransmission/bitfield.cc:233)
fish: Job 1, 'transmission-gtk' terminated by signal SIGABRT (Abort)

[rpatterson]

After having seen rpatterson's "fix" of adding the config directory

That wasn't intended to describe a fix, rather to describe how I reproduced the issue. IOW, running $ transmission-daemon ... under v3.0 with a given set of torrents works. Running the same under v4.0 causes the error described in this issue dscription. I think we might actually be in agreement but I'm not sure. Are you saying you observe the same problem as described in the issue description when running an existing set of torrents under v4.0 but that you do not observe the problem when you run that same set of torrents under v3.0, @boomboxnation?

[Eamourinho]

I'm experiencing this too ever since 4.0 got released, same linuxserver/transmission docker implementation

[rpatterson]

I'm experiencing this too ever since 4.0 got released, same linuxserver/transmission docker implementation

Oh, in case it helps, this is how I'm keeping the image at v3.0 until this issue is resolved. Also, maybe give a thumbs up reaction to the issue, @Eamourinho @boomboxnation in the hopes of drawing attention to this.

[ckerr]

For one thing I don't understand why these builds are being made with assertions enabled, e.g. why that Docker image has assertions at all. Those shouldn't make it into production code; they're only meant for test builds.

Whoever made that Docker image should've called cmake with -DCMAKE_BUILD_TYPE=Release or -DCMAKE_BUILD_TYPE=RelWithDebInfo.

[thespad]

We don't build transmission from source for the image, we install from the Alpine repos. If there's an issue with the package it should be reported to their maintainers.

[rpatterson]

For one thing I don't understand why these builds are being made with assertions enabled

FYI, this is the "official" image in the sense that it's the one linked to from the official download page.

Whoever made that Docker image should've called cmake with -DCMAKE_BUILD_TYPE=Release or -DCMAKE_BUILD_TYPE=RelWithDebInfo.

I went ahead and commented on an existing issue regarding this.

[rpatterson]

Those shouldn't make it into production code; they're only meant for test builds.

To clarify, I assume this doesn't mean this issue will be resolved by disabling assertions, @ckerr?

[nekopsykose]

it is, the assertions are from

transmission/libtransmission/tr-assert.h

Line 8 in 2b35785

#if !defined(NDEBUG) || defined(TR_FORCE_ASSERTIONS)

transmission/libtransmission/tr-assert.cc

Line 13 in 2b35785

#if !defined(NDEBUG) || defined(TR_FORCE_ASSERTIONS)

and are dropped when NDEBUG is defined.

the implicit cmake behaviour is when you pass any of the three "release types" (those being MinSizeRel, Release, RelWithDebInfo (i'm pretty sure it's just the Rel substring)), cmake adds -DNDEBUG.

[rpatterson]

it is

Can you clarify, @nekopsykose? Is that in reference to my previous comment?

[rpatterson]

I no longer see the assertion errors running the latest Docker image, but I'm still unclear if that's just hiding a real underlying issue.

[ckerr]

related: https://retrace.fedoraproject.org/faf/problems/bthash/?bth=b350cbeb1debd5b1654f68c2a1320c098d74a8e3&bth=8b70bd742b7839089fa8399e5db24e001ca248cb&bth=f583ff12c77a28a072a6a7d784c33361d63cc853

[rpatterson]

related: https://retrace.fedoraproject.org/faf/problems/bthash/?bth=b350cbeb1debd5b1654f68c2a1320c098d74a8e3&bth=8b70bd742b7839089fa8399e5db24e001ca248cb&bth=f583ff12c77a28a072a6a7d784c33361d63cc853

How is that related? It's not obvious from looking at that link.

[ckerr]

@rpatterson appears to be the same assertion failure in tr_bitfield::setTrueCount()

[rpatterson]

It seems like there may be a real issue underlying this somewhere, but what I encountered is long since resolved.