From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id aPsXOc/YmWgV0wkAWB0awg (envelope-from ) for ; Mon, 11 Aug 2025 07:49:35 -0400 Received: by simark.ca (Postfix, from userid 112) id E7BAF1E10A; Mon, 11 Aug 2025 07:49:35 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-9.0 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED, RCVD_IN_VALIDITY_RPBL,RCVD_IN_VALIDITY_SAFE autolearn=ham autolearn_force=no version=4.0.1 Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 4928E1E097 for ; Mon, 11 Aug 2025 07:49:35 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id EDC6E3858C36 for ; Mon, 11 Aug 2025 11:49:34 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org EDC6E3858C36 Received: from mail-wr1-f41.google.com (mail-wr1-f41.google.com [209.85.221.41]) by sourceware.org (Postfix) with ESMTPS id AC69E3858C74 for ; Mon, 11 Aug 2025 11:49:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org AC69E3858C74 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org AC69E3858C74 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=209.85.221.41 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1754912943; cv=none; b=hqH1jHGpO4Eepz+wc6kxbF4cTvl8ci4Z1l/s07EJsj6ed/2BAxuDm2imyBwyCP4B7dxXSsC47Qd8IxXfJKvlzGTPGArrMnXl8NTCPNBsNZAyLsaYTNv4knvEGTRok+KCKxv3Oct0XIOCeeayAyrugD0PI6VhErzoXMR/hkpfULU= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1754912943; c=relaxed/simple; bh=xt3JpzEpNcRIgHhwA43oIE9mqpBq4sOkMtYpy69BUNM=; h=Message-ID:Date:MIME-Version:Subject:To:From; b=AYrIObw2tXonrUAy3PKzord1krkqZaKh9YIXE0C8f3bPZ2eSbQIU8vrFuqYERpFRa3oGjiaN8sLehn636Ensn+2pfs+hc8MybNogK09GuUJNkkEZm4tQ1OPmMmgvGw37T78Ph/Uh/X62bDc8KFcYKoWXCALuFACSaQW7GgsrLoQ= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org AC69E3858C74 Received: by mail-wr1-f41.google.com with SMTP id ffacd0b85a97d-3b78127c5d1so2749275f8f.3 for ; Mon, 11 Aug 2025 04:49:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1754912942; x=1755517742; h=content-transfer-encoding:in-reply-to:content-language:from :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=7R+SkaQzWV46M0uVA6K3IPEpcVLjZ5KG9hBfeE7vitk=; b=qsi36BBDYZfySIJUyjJDiMoYlwjynOlZKPD7K7wWEEEvM4u6P3uOW5NX6JQcXHvCZg /xXD4jxzpm+bELECPpuNLMvquJ2F5BQUgvZidLsqVvVeFZp195vf4lGVx1YId1MCL6TM Lrgs0AwwKSkZmOGUL2csOrGUN34bvqByY6CwGaNodKzJ9S1jz4IBjqrnmK4tDCUPdYo0 tMzdigOS8I+GRMy/WMoITzibdAdCB3+uPAgupGcbUWXbpJVpbMMVUCWBpltuFmjgran7 TUvs60Oy1wHO+ohXRPvsL5FD3s6fYHOdCpvJyPSaZAR50qZ6SnExY4hJZqdlMeNCumjE te6A== X-Gm-Message-State: AOJu0YzW3y1A0wMgSiy/ekEaufJTtRhjT/JTvxl4Hsk0WN8EhLAw18IJ LaMy6Z6k8uj6GUGdjaISHS8gAjWGH0F1Z+gsqf1rEayrtZVC+eVZ0je/1Ti22sZd X-Gm-Gg: ASbGncuyVzaTG/Y3RbhRxIVNLQPYzpYbBYPkM58K4+VGgcrklLAFQbwiqyfPOPGWIcY Jt8CSt2tTvs1iN5ftWIl8jtvYZWvi9BvE440DHzTJT6EF7NDQJLstyn78rho+AXJ95vTc+O4ePF cUVH/tDQC7tXPJDw3OINxfv+GcMvApfwkoG3em607fNHScclMYdLmqFYhHNxPSTeUzD51DLHCN3 3rCYdekyGqZguBXNgR8+jKydwn7vLE38Y7KBSJaBH/HJlsfl+38bIjowFM/+WnUW1CyNPPQ4Ber NoPa2KgRxDtlZf2mT74eyYrK2Up2JNj+rfQMsVMoDvHJ4smwg2ZOMk0k3GIEUbOhIVudpNJjxOd lwnCxx3cf2KxCfNid7Tly0teV/Rvgt8Phs2JF7rYNKC2RYZ3G/sizk5rnQN8= X-Google-Smtp-Source: AGHT+IEeCjPxOG2aKXdSpEqm3chnvz8g2xHV/nIzkug7fQPl/c6Y2faFi8yhVuRR7w9mXSgl6WNJXQ== X-Received: by 2002:a05:6000:40de:b0:3a0:b84d:60cc with SMTP id ffacd0b85a97d-3b900929b68mr10862653f8f.2.1754912942045; Mon, 11 Aug 2025 04:49:02 -0700 (PDT) Received: from [192.168.0.201] (bl21-214-172.dsl.telepac.pt. [2.82.214.172]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3b79c4a2848sm39826350f8f.71.2025.08.11.04.49.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 11 Aug 2025 04:49:01 -0700 (PDT) Message-ID: Date: Mon, 11 Aug 2025 12:48:55 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] testsuite: Introduce gdb_watchdog (avoid unistd.h/alarm) To: Kevin Buettner Cc: gdb-patches@sourceware.org References: <20250808225050.1761370-1-pedro@palves.net> <20250809202851.500f1572@f41-zbm-amd> From: Pedro Alves Content-Language: en-US In-Reply-To: <20250809202851.500f1572@f41-zbm-amd> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org On 2025-08-10 04:28, Kevin Buettner wrote: > Hi Pedro, Hi! > > On Fri, 8 Aug 2025 23:50:50 +0100 > This all sounds reasonble to me. > > One possible nit, and it's *way* outside my wheelhouse, so feel free to > ignore it... > > [...] >> +static VOID CALLBACK >> +_gdb_watchdog_timer_routine (PVOID lpParam, BOOLEAN TimerOrWaitFired) >> +{ >> + fputs (_gdb_watchdog_msg, stderr); >> + fflush (stderr); > > On POSIX, fputs and fflush are not async-signal-safe. It's my > understanding that they aren't on WIN32 either, but I don't know > whether this is actually a signal handler. There isn't actually a concept of async-signal-safety on Windows. Signal handlers don't run on the mainline code's preempted stack, like happen on POSIX. Instead, Windows runs the signal handler on a system-created thread, concurrently with mainline code. In this case, we don't have a signal handler, but it's basically the same thing. The timer runs on a separate thread (Windows thread-pool thread in this case). So the concern here would be the same concern with any two threads calling into fputs/fflush at the same time. The stdio routines are thread safe, in that they serialize access to FILE* streams with a per-stream internal lock, so simultaneous fputs calls to the same stream from different threads won’t corrupt the stream's buffer. I think that the only case where a call to fputs/fflush here could block indefinitely, is if they end up blocking inside the internal WriteFile they do, say, because they are writing to a full pipe and the reading end isn't consuming input. But for that scenario, going directly to WriteFile won't help either, it will block the same way. This is exactly the same for the write call on the POSIX side, BTW. I think the only way to avoid this would be if we tried to open the handle with FILE_FLAG_OVERLAPPED and do async writes, but that adds complexity and the watchdog thread must pump the overlapped completion or timeout logic. Similarly, on the POSIX side we'd have to make sure to do an async write. Or we could just not print anything. abort() is a CRT function too, and it flushes streams (hmm, maybe I don't need the fflush after all), and if we were to avoid fputs/fflush to avoid locks, then I'd think that we would want to avoid abort too. Maybe call ExitProcess or TerminateProcess directly? However, I was thinking that using abort() could be nice for leaving it open the possibility making Windows generate a minidump or for hooking Windows's crash reporting mechanism with cygwin's dumper to generate an ELF core dump if we wanted, or something of the sort. I suppose we could still have that if we terminate the process with something at the Win32 level that triggers the same mechanisms, like maybe raise an uncaught exception? Dunno. fputs + abort just seems appealing to me for being simple, and abort() being the same that we do on the POSIX side. And in the end I think it's like you say -- I doubt it matters much. > > Regardless, the rest LGTM. And even if fputs and fflush aren't > async-signal-safe in this context, I doubt that it matters much. > > So... > > Approved-by: Kevin Buettner >