Moret84
commented
1 year ago I have investigated by debugging the code and found out from where rtorrent crashes.
In file src/core/poll_manager.c, in create_poll method, the value of the sys variable _SC_OPEN_MAX is queried.
The got value is then passed to the PollEPol::create constructor, which uses it to resize its internal m_table.
The array is an array of std::pair<uint32_t, Event*>. Size of element is hence 16.
The issue is that for some unknown reason, the _SC_OPEN_MAX value is huge on my system: 1073741816.
The requested array resize hence requests a 1073741816 * 16 = 17179869056 bits = 2,147483632 gigas byte array.
This is more than the available memory on my docker host.
I have tried on an other docker host that has 24 Go RAM, and the _SC_OPEN_MAX is only 1048576.
You can make rtorrent working again by hard setting _SC_OPEN_MAX for your docker container with ulimit:
docker run --rm -v --ulimit nofile=300:300 your-image ./myapp
Maybe rtorrent should complain about this error rather than just throwing cryptic std::bad_alloc error.
Hi,
I used to run rtorrent inside a docker container with rutorrent and nginx. The host is a archlinux box and hence often updates. I suspect any update broke something because rtorrent can't be launch anymore. The only output I get is: rtorrent: std::bad_alloc. I tried running rtorrent inside gdb. Crash immediately happens, but bt gives "No stack". The crash must occurs at the very beginning of the program, because even running with help flag produces it. I was suspecting the alpine musl (base image of my container), but it turns out that occurs with debian too. I found out a topic on SO of a random guy who encounter the same issue. Sadly, no response as of now.
Any clue about this issue ? How can I investigate more ?