View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0008200 | ardour | bugs | public | 2020-06-04 10:11 | 2020-08-03 10:12 |
| Reporter | mvf | Assigned To | x42 | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Platform | x86_64, glibc 2.30, GCC 9.3.0 | OS | Void Linux | OS Version | rolling |
| Product Version | 6.0 | ||||
| Summary | 0008200: Fatal Error: "Cannot create thread for TaskList!" | ||||
| Description | When starting a session, Ardour 6 always fails with the following error message box: Ardour - : Fatal Error "Cannot create thread for TaskList!" [Press To Exit] | ||||
| Steps To Reproduce | 1. Start "ardour6" on Void Linux (not yet packaged, see https://github.com/void-linux/void-packages/pull/22134) 2. In the initial "Session Setup" dialog, click "New Session" 3. In the second "Session Setup" dialog, select "Empty Template" and click "Open" 4. In the "Audio/MIDI Setup" dialog, click "Start" | ||||
| Additional Information | Cause: Commit 3d166c77891c2a83de35c5fd10c0b23c131bc43b reduced the stack size for the TaskList thread (and others) from 100 to 32 KiB. On my machine that's not even enough for the static TLS block (43584 bytes), and pthread_create fails with EINVAL. Workaround proposed to downstream maintainer: libs/pbd/pbd/pthread_utils.h: #define PBD_RT_STACKSIZE_PROC 0x20000 // 128kB -#define PBD_RT_STACKSIZE_HELP 0x08000 // 32kB +#define PBD_RT_STACKSIZE_HELP PBD_RT_STACKSIZE_PROC Downstream discussion: https://github.com/void-linux/void-packages/pull/22134 | ||||
| Tags | No tags attached. | ||||
|
|
thanks for tracking this down. But I wonder which system component is causing that, since this doesn't seem to be an issue on most/all linux systems that the folks on IRC are using (for example) |
|
|
The intention here is to optimize context switches of rt-thread, and those threads should not use a lot of data on the stack. We use -fPIC so gcc's default is -ftls-model=global-dynamic and the default TLS size should be 1KB in ELF. How did you find out about the size (43584 bytes) on your machine? Is this from a custom pthread build? If the solution ends up being increasing the size, PBD_RT_STACKSIZE_PROC likely also needs to be increased. There can be 8k float (32kB) buffers in addition to PBD::StackAllocator<> for channel-mappings. |
|
|
> this doesn't seem to be an issue on most/all linux systems that the folks on IRC are using (for example) From what I learned today, this is starting to look like a Void Linux issue to me. > How did you find out about the size (43584 bytes) on your machine? Is this from a custom pthread build? Using the unmodified distro libs, I stepped into pthread_create to the point where it bails [1] and inspected the __static_tls_size variable. Today I debugged the linker and found that cairo and its pixman dependency hog most of that TLS space: Reading symbols from /lib/ld-linux-x86-64.so.2... (gdb) b _dl_determine_tlsoffset Breakpoint 1 at 0x11960: file ../elf/dl-tls.c, line 141. (gdb) r /usr/lib/ardour6/ardour-6.0.0 Starting program: /usr/lib/ld-linux-x86-64.so.2 /usr/lib/ardour6/ardour-6.0.0 Breakpoint 1, _dl_determine_tlsoffset () at ../elf/dl-tls.c:141 141 ../elf/dl-tls.c: ??????????????????????. (gdb) set $slot = _rtld_local._dl_tls_dtv_slotinfo_list->slotinfo (gdb) while $slot->map > printf "%s: %lu\n", $slot->map->l_name, $slot->map->l_tls_blocksize > set $slot = $slot + 1 >end /usr/lib/libcairo.so.2: 13784 /usr/lib/libstdc++.so.6: 32 /usr/lib/libc.so.6: 144 /usr/lib/libuuid.so.1: 74 /usr/lib/libpixman-1.so.0: 24960 /usr/lib/libmount.so.1: 6 /usr/lib/libasound.so.2: 8 /usr/lib/libGLdispatch.so.0: 8 /usr/lib/libblkid.so.1: 6 /usr/lib/libgnutls.so.30: 16 /usr/lib/libOpenCL.so.1: 4 /usr/lib/libp11-kit.so.0: 513 And sure enough, linking a minimal program against cairo gives a __static_tls_size of 43008 bytes. Doing the same on Ubuntu focal and Debian bullseye, __static_tls_size is only 4608. [1] https://github.com/bminor/glibc/blob/1ba9ebfce371cea8ab1cd5f1577a18d2f1a8c863/nptl/allocatestack.c#L538 |
|
|
Nice detective work! Reading some of the linked glibc source, gave me an idea. Can you try Ardour 6.0-69-ge0548fa798? https://github.com/Ardour/ardour/commit/e0548fa798e now adds the current TLS size to the requested size. |
|
|
Great idea, this seems to work. __pthread_get_minstack returns 64064 and Ardour successfully requests 80448 bytes of stack. I opened a PR [1] with some additional fixes in this area. Many thanks for the support! [1] https://github.com/Ardour/ardour/pull/524 |
|
|
Patch applied. Fixed in 6.0-80-ge3dcd1f5d7 |
|
|
Issue has been closed automatically, by Trigger Close Plugin. Feel free to re-open with additional information if you think the issue is not resolved. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2020-06-04 10:11 | mvf | New Issue | |
| 2020-06-04 21:27 | paul | Note Added: 0024393 | |
| 2020-06-04 22:20 | x42 | Note Added: 0024394 | |
| 2020-06-06 13:28 | mvf | Note Added: 0024421 | |
| 2020-06-06 17:07 | x42 | Note Added: 0024423 | |
| 2020-06-06 17:07 | x42 | Assigned To | => x42 |
| 2020-06-06 17:07 | x42 | Status | new => feedback |
| 2020-06-08 06:35 | mvf | Note Added: 0024434 | |
| 2020-06-08 06:35 | mvf | Status | feedback => assigned |
| 2020-06-09 21:57 | x42 | Status | assigned => resolved |
| 2020-06-09 21:57 | x42 | Resolution | open => fixed |
| 2020-06-09 21:57 | x42 | Note Added: 0024445 | |
| 2020-08-03 10:12 | anonymous | Note Added: 0024884 | |
| 2020-08-03 10:12 | anonymous | Status | resolved => closed |
