View Issue Details

IDProjectCategoryView StatusLast Update
0008200ardourbugspublic2020-08-03 10:12
Reportermvf Assigned Tox42  
Status closedResolutionfixed 
Platformx86_64, glibc 2.30, GCC 9.3.0OSVoid LinuxOS Versionrolling
Product Version6.0 
Summary0008200: Fatal Error: "Cannot create thread for TaskList!"
DescriptionWhen 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 Reproduce1. Start "ardour6" on Void Linux (not yet packaged, see
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 InformationCause:
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:
 #define PBD_RT_STACKSIZE_PROC 0x20000 // 128kB
-#define PBD_RT_STACKSIZE_HELP 0x08000 // 32kB

Downstream discussion:
TagsNo tags attached.



2020-06-04 21:27

administrator   ~0024393

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)


2020-06-04 22:20

administrator   ~0024394

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.


2020-06-06 13:28

reporter   ~0024421

> 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/
(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/ /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
/usr/lib/ 13784
/usr/lib/ 32
/usr/lib/ 144
/usr/lib/ 74
/usr/lib/ 24960
/usr/lib/ 6
/usr/lib/ 8
/usr/lib/ 8
/usr/lib/ 6
/usr/lib/ 16
/usr/lib/ 4
/usr/lib/ 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.



2020-06-06 17:07

administrator   ~0024423

Nice detective work!

Reading some of the linked glibc source, gave me an idea. Can you try Ardour 6.0-69-ge0548fa798? now adds the current TLS size to the requested size.


2020-06-08 06:35

reporter   ~0024434

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!



2020-06-09 21:57

administrator   ~0024445

Patch applied. Fixed in 6.0-80-ge3dcd1f5d7


2020-08-03 10:12

viewer   ~0024884

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.

Issue History

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