From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-x32d.google.com (mail-ot1-x32d.google.com [IPv6:2607:f8b0:4864:20::32d]) by sourceware.org (Postfix) with ESMTPS id 55B163858C5F for ; Thu, 11 May 2023 17:31:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 55B163858C5F Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-ot1-x32d.google.com with SMTP id 46e09a7af769-6ab0bad2587so3150498a34.3 for ; Thu, 11 May 2023 10:31:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683826274; x=1686418274; h=cc:to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=cvoh8Ekc06bW6GxgSy3Hl6UJzYf1jvbZgAmgoHWtJYM=; b=LTgIuO1nVtlD8Aqh51/eZT1yDkivvCTPIuSjFRGadf1LaJB+POZ7wzrYv+43cM448J y4b20txd5oJguAzx6RXwow4Cc37oB+FM/PRbPctcZWHpYhPKOwrbo/tm4gTt6irTtD1D Rrv84polvN5c1bbGgr4aL+cIkuhFmQG0srPLtAOs95C1D49VnEi20qqYWysNeenOxxYG OPQJ26+3ilj5AnlcOKceRdqwLlbkw75Gmo+C4j3V8ju4dYkFntXMC0vNDrFE30h/OeFF gf4skC7iEglN13zGmMHDzTA7MDDMQZfTgBzqZkZskOPQ3F9oF7t4TTir8bWPqD/v49AN Wglg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683826274; x=1686418274; h=cc:to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=cvoh8Ekc06bW6GxgSy3Hl6UJzYf1jvbZgAmgoHWtJYM=; b=htg9pSRVVpF3g+siTTKFafDAFrqnGFZiRfHrO34KcziEI2lpM1TeZjBDK+mvTTkh0M JiAeUojED0S1yX+pBs94liE1uBLkU/MHZ/f2dJhd4FNVDaofc7ygeFIvvSiBaN9NBhxr YKWB8G3FDkBgfaQhsmr3SsZYaWsLBcl0HL7/UFGL8tV2m9u4E5VcVZ37wBLlNjShmgNA rD5cxfVaPut51pBxCJvkx5XCMn0bxGg6+H3zrU+xVC9EMYYmngE4mU08K52cNDOmVJLp v6T4ao7yuGzFCrZLt/rVC4PLbQg++BjGjirUHw21s3ydFeJJveLoRdAJMx8Mmop/Nt3K Rw/w== X-Gm-Message-State: AC+VfDxsx3LLnd+4rkxXWbNKkHiahIOTap5aW0YxvCLJWH9PoAdyS5ct G1nJ0ssE6Y2j2ax9Yvhpt3Org4xbjcWR+1R4nvmh59Xk2G4= X-Google-Smtp-Source: ACHHUZ5/EWUZgFMVoYZgch2YQ1UZPnaZiSAb9x1xocqwmc//VFm977/5SBpWWm13PjZ2c/Qqxt2U6oSYuBN21QIyPs8= X-Received: by 2002:aca:2b0d:0:b0:38d:e85e:e7e9 with SMTP id i13-20020aca2b0d000000b0038de85ee7e9mr5175883oik.9.1683826274425; Thu, 11 May 2023 10:31:14 -0700 (PDT) MIME-Version: 1.0 From: Sergey Bugaev Date: Thu, 11 May 2023 20:31:03 +0300 Message-ID: Subject: __pthread_setcancelstate called unconditionally, crashes at 0 To: libc-alpha@sourceware.org, bug-hurd Cc: Florian Weimer , Samuel Thibault Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,KAM_NUMSUBJECT,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hello, I'm hitting a crash with the following backtrace: #0 0x0000000000000000 in ?? () #1 0x00000000004660dd in __error_internal (status=1, errnum=1073741826, message=0x9adcef1c, args=0x9adcef18, args@entry=0x156aa48, mode_flags=2598170400, mode_flags@entry=0) at error.c:243 #2 0x00000000004661d5 in __error (status=status@entry=0, errnum=, message=) at error.c:274 #3 0x0000000000401497 in error (__format=, __errnum=, __status=) at error.h:42 Note that PC is 0 in the top frame. Here's the relevant listing and backtrace of the frame #1: (gdb) l 238 { 239 #if defined _LIBC 240 /* We do not want this call to be cut short by a thread 241 cancellation. Therefore disable cancellation for now. */ 242 int state = PTHREAD_CANCEL_ENABLE; 243 __pthread_setcancelstate (PTHREAD_CANCEL_DISABLE, &state); 244 #endif 245 246 flush_stdout (); 247 #ifdef _LIBC (gdb) disas Dump of assembler code for function __error_internal: 0x00000000004660b0 <+0>: push %r14 0x00000000004660b2 <+2>: mov %r8d,%r14d 0x00000000004660b5 <+5>: push %r13 0x00000000004660b7 <+7>: mov %rcx,%r13 0x00000000004660ba <+10>: push %r12 0x00000000004660bc <+12>: mov %rdx,%r12 0x00000000004660bf <+15>: push %rbp 0x00000000004660c0 <+16>: mov %esi,%ebp 0x00000000004660c2 <+18>: push %rbx 0x00000000004660c3 <+19>: mov %edi,%ebx 0x00000000004660c5 <+21>: xor %edi,%edi 0x00000000004660c7 <+23>: sub $0x10,%rsp 0x00000000004660cb <+27>: lea 0xc(%rsp),%rsi 0x00000000004660d0 <+32>: movl $0x1,0xc(%rsp) 0x00000000004660d8 <+40>: call 0x0 => 0x00000000004660dd <+45>: mov $0x569b10,%rax 0x00000000004660e4 <+52>: mov (%rax),%rdi 0x00000000004660e7 <+55>: call 0x433900 <_IO_fflush> "call 0x0", ouch! Clearly __pthread_setcancelstate has been pragma weak'd, and used here without a check. This is a statically linked x86_64-gnu (so, Hurd and HTL) executable. Commit 93d78ec1cba68184931b75bef29afd3aed30f43a "nptl: Move pthread_setcancelstate into libc" seems to be the culprit: that commit only moved the NPTL symbol into libc, yet changed the original __libc_ptf_call (__pthread_setcancelstate) calls to direct __pthread_setcancelstate calls, in this and many other places. This likely hasn't been noticed in the past because the only statically linked executables typically used on Hurd systems are the few bootstrap servers, and they're (presumably) all multithreaded. What would be the best way to get this fixed? (other than eventually moving htl into libc) Are the other pthread symbols also used unconditionally? Is there, or should there be, a test for this? Sergey