Created attachment 10556 [details] Modified version of nptl/tst-cond1.c The attached program works well on glibc <= 2.24. It has the following packed structure: struct thread_info_t { pthread_mutex_t mut; char c; pthread_cond_t cond; }; If it's compiled on a glibc <= 2.24 machine and copied to a glibc >= 2.25 machine, it aborts. Confirmed on x86_64 and powerpc64le.
(In reply to Tulio Magno Quites Machado Filho from comment #0) > Created attachment 10556 [details] > Modified version of nptl/tst-cond1.c > > The attached program works well on glibc <= 2.24. > > It has the following packed structure: > > struct thread_info_t > { > pthread_mutex_t mut; > char c; > pthread_cond_t cond; > }; > > If it's compiled on a glibc <= 2.24 machine and copied to a glibc >= 2.25 > machine, it aborts. > > Confirmed on x86_64 and powerpc64le. In 2.25 we had the new pthread_cond_t. Are we missing explicit padding somewhere to avoid problems with user use of pragma pack(1)? I'm not entirely worried this isn't working, it's a bad idea to use pragma pack(1) like this, and it should be avoided, but since it worked previously, we probably need to audit any missing explicit padding?
That it appeared to work previously is irrelevent, because it has always been broken. The kernel requires 32-bit alignment of futex variables.
(In reply to Carlos O'Donell from comment #1) > Are we missing explicit padding somewhere to avoid problems with user use of > pragma pack(1)? No. The problem happens because of atomic instruction that are not aligned at their natural boundary. (In reply to Andreas Schwab from comment #2) > That it appeared to work previously is irrelevent, because it has always > been broken. The kernel requires 32-bit alignment of futex variables. For the record, it also fails with pragma pack(4). Tested on powerpc64le.
Re-opening this bug, so that my previous comment receive a reply.
(In reply to Tulio Magno Quites Machado Filho from comment #4) > Re-opening this bug, so that my previous comment receive a reply. There isn't much to say really. It's not supported. You have to know *exactly* how every structure in the packed structure is going to be accessed and if that's safe. In the case of POSIX threads, the person packing the structure doesn't know how it will be accessed, and violating the ABI by packing is a failure of the programmer. In some cases we can make this *safer* by introducing explicit padding, but the lead element can still be unaligned, and there is not way to fix that. It can fail with any forced packing that happens to not honour what the actual structures need, including pack(4), on hppa you needed aligned(16) for the ldcw to work! I think this is still a RESOLVED/INVALID use case.
Thank you for the clarification!