From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id E00F63858D28 for ; Mon, 7 Aug 2023 09:00:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E00F63858D28 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1691398800; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=ELjv1ZUAMAkkgw/7jJV3xM7fqVt6SQZaH+CUxXFIEU0=; b=AHIfStyqY33rLUJfFJH/421Hv8nPf1YcT5B7uGhsbAsmkMNLZU4ND0vo+yqEPDINNv0rHN 4jbNY+vy44erCG0KoB/bcNXHPnlRtKrXqC3mGuykOdkeJxjc12NTEjFDP8NkOhW01+kgkX J1LE7WtQ9kinTBkiCd80KVucVAH2F+M= Received: from mimecast-mx02.redhat.com (66.187.233.73 [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-154-k09yYiKAMzu-Z2Udff5SVg-1; Mon, 07 Aug 2023 04:59:57 -0400 X-MC-Unique: k09yYiKAMzu-Z2Udff5SVg-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 08DA73C0FC83; Mon, 7 Aug 2023 08:59:57 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.2.16.12]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 90B3E1759C; Mon, 7 Aug 2023 08:59:56 +0000 (UTC) From: Florian Weimer To: Paul Wise via Libc-help Cc: Paul Wise Subject: Re: is this a bug in glibc or readpst? References: <2cefc4fa95dd439c2581f4f06d520c004cd33708.camel@bonedaddy.net> <875yf6nj43.fsf@oldenburg.str.redhat.com> <87ilitpv06.fsf@oldenburg.str.redhat.com> Date: Mon, 07 Aug 2023 10:59:55 +0200 In-Reply-To: (Paul Wise via Libc-help's message of "Sun, 06 Aug 2023 14:07:09 +0800") Message-ID: <874jlbi5x0.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.5 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: * Paul Wise via Libc-help: > Looking at the stack traces, the _IO_SYNC call introduced in the commit > 0b727ed4d that I identified as triggering the readpst bug is definitely > the source of the lseek call. > > lseek(3, -2138, SEEK_CUR) = 268198 > > /lib/x86_64-linux-gnu/libc.so.6(lseek64+0x7) [0xf81b7] > > /lib/x86_64-linux-gnu/libc.so.6(_IO_file_sync+0x7e) [0x800ae] > > /lib/x86_64-linux-gnu/libc.so.6(freopen+0x8c) [0x7d95c] > > /usr/bin/readpst(pst_reopen+0x36) [0x102c6] > > /usr/bin/readpst(try_fork+0x88) [0x4398] > > /usr/bin/readpst(process+0x121) [0xa451] > > /usr/bin/readpst(main+0x555) [0x3cc5] > > /lib/x86_64-linux-gnu/libc.so.6(__libc_init_first+0x8a) [0x271ca] > > /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x85) [0x27285] > > /usr/bin/readpst(_start+0x21) [0x4061] > > Based on the same thing happening with fflush+fclose+fopen, I'm not > entirely sure, but I think that this represents a POSIX compliance bug > in readpst that was papered over by the earlier behaviour of glibc. We could perhaps avoid the seek for read-only streams. We are about to close the stream anyway, so fflush does not have any useful effect anyway. Not sure what others think if it is worth the complexity. On the other hand, preserving backwards compatibility here does not appear to be too onerous. Thanks, Florian