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.129.124]) by sourceware.org (Postfix) with ESMTPS id A9B393857707 for ; Mon, 5 Jun 2023 06:40:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A9B393857707 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=1685947202; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=KMDwAb8qAuItTODSphxp381ytvzKsDgordyeV2b3zvk=; b=ZfmMjSsAHHHrxoHoi/s+VTUN/8xmfI/b/OSPOKZRv3vbVaDY/bRy8pBgcPS38Kr6sgcPLr Br745vJolbdG21LYqviJrWYfpcAmVTH+PAMnfbLsmE0diqclOI+bB1w/89rkENjqtlG5ho ockDgCxACOL8EMF6wuAiaZ17aIekntE= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [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-529-u54i8X8_N5el_YB2aK8Fwg-1; Mon, 05 Jun 2023 02:39:59 -0400 X-MC-Unique: u54i8X8_N5el_YB2aK8Fwg-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 299C038184E0; Mon, 5 Jun 2023 06:39:59 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.2.16.27]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 521F57AE4; Mon, 5 Jun 2023 06:39:58 +0000 (UTC) From: Florian Weimer To: Konstantin Kharlamov Cc: libc-help@sourceware.org Subject: Re: Q: System behaviour in out of memory situation References: Date: Mon, 05 Jun 2023 08:39:56 +0200 In-Reply-To: (Konstantin Kharlamov's message of "Mon, 05 Jun 2023 03:28:00 +0300") Message-ID: <87pm6a1kg3.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; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-4.8 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE 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: * Konstantin Kharlamov: > 2. Is it unrealistic to expect ENOMEM from `malloc()`? That is because > =CE=B1) most systems have OOM-killer enabled, so instead of ENOMEM some a= pp > will get killed =CE=B2) In absence of OOM-killer you'll get virtual memor= y > successfully allocated, which returns us to 1. malloc can return ENOMEM for other reasons, for example if the available address space is exhausted, or if the kernel mapping limit per process is exceeded. Thanks, Florian