From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx07-00178001.pphosted.com (mx07-00178001.pphosted.com [185.132.182.106]) by sourceware.org (Postfix) with ESMTPS id D2CA63856DCF for ; Sat, 17 Sep 2022 09:01:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D2CA63856DCF Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=st.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=st.com Received: from pps.filterd (m0241204.ppops.net [127.0.0.1]) by mx07-00178001.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 28H7tRgf010101; Sat, 17 Sep 2022 11:01:19 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=st.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=STMicroelectronics; bh=h+JZEeFCU4JyZ73OufDAQ9h31+93JEe/r9uEU+AOMKM=; b=FsJw3ub+32clUCMAHGjP3lShNYvjPWjN7kGreMh7YYq7plSmLoKFcuXrQp9XqaZV5lmi z8LQMieKvT8wYGN9lQe6ZWk9gav/++nrflAxmTSXGWnWsiCLOPXzhvdTt2bzNVAl8vY7 P446X1VwXlEtImrLlEFPe1HWp6UsB/M8cU6kmsk+H/FsCgEF/o+KV7sqOeZEgEUkEWIX /upRMcJ4bMXrNHCA57bHDldB60YNl7oZoRUSx3BSGg78DvEVu6Ytwzft1qXXBCumclsH rhb3l+aRpGDEA1gYFzMhxmkFxJNt/IsVa1N8HU+b9f86Toe4VutHtFI0B26mvpcU4kk1 JQ== Received: from eur03-dba-obe.outbound.protection.outlook.com (mail-dbaeur03lp2168.outbound.protection.outlook.com [104.47.51.168]) by mx07-00178001.pphosted.com (PPS) with ESMTPS id 3jn6g4ru15-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 17 Sep 2022 11:01:19 +0200 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dhSyBwFFEFWHicmhiviLOgV61w4rW5sTyLRembm3oVIfviy1Hacv7lriyprqJ5xlgwmKZjEOyFlkiiI4RpZo42kF+OqwbJrDWrvN28rmR2HZLe6oRv0uo7xR4LOlHJnUGn/p7015x9ty1nRG8g2/QiL9FaUq17jkzt3A8HH6GIESltDoK40vEhNzUEk5PCTMtdtjvSKr6fWLNL19NvaIZGQn1AA1ZM3CnH0C8Wg8a2f0b3dLLZ9HL8D3DvFJvP9vJIf2IxljLCD1Jqpr79KgwGTI0C1KucmVDBLs6s0Vgv8Kt1Xn7gal3wKIdaiDjG3IEe+ae8xaS2iKBBbDw67kvw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=h+JZEeFCU4JyZ73OufDAQ9h31+93JEe/r9uEU+AOMKM=; b=M7NntWPTJo1jxLyIdp5k/9+IKB7YJs4HmrkI9HRUT1++17jwutlQxmJbmvleGnCWcMPfvF8xCOQ6XVZ2po0eXxhp65ISgUDnSbU/UJ42DngybmereCVQB7NFfhy2LxbIZpkV3TxxE8DXv6uaBthiAju1etAm7F30kI6VDmt3oYfGWM70b/v6KanGshhAMakv6Crm9zo9ZcdYimiA/341OBDH8JbSkimVHeOwPhX7j5OQ/fk7WgMCb35kHeducpGtZxd3hupLoJCH91yX2ahNpXhY0jfo0Ucj+iNQtTVEhzqN5fG01+c8i07WQKy3gc8YZPC7zJcbGScLECb13SCIHQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=st.com; dmarc=pass action=none header.from=st.com; dkim=pass header.d=st.com; arc=none Received: from AM6PR10MB2197.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:20b:41::30) by DU0PR10MB5704.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:10:313::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5632.17; Sat, 17 Sep 2022 09:01:17 +0000 Received: from AM6PR10MB2197.EURPRD10.PROD.OUTLOOK.COM ([fe80::85b:8865:5c30:475e]) by AM6PR10MB2197.EURPRD10.PROD.OUTLOOK.COM ([fe80::85b:8865:5c30:475e%3]) with mapi id 15.20.5632.018; Sat, 17 Sep 2022 09:01:17 +0000 From: Torbjorn SVENSSON To: Jeff Johnston CC: Jerome Leroux , "newlib@sourceware.org" , Niklas DAHLQUIST Subject: RE: Malloc: unusable area at the end of the heap section Thread-Topic: Malloc: unusable area at the end of the heap section Thread-Index: AQHYeetJCKgFbYlDZEKjkeeBpfCcv61Ddy3ggAClU4CAm+dagIADGf8AgADVVzA= Date: Sat, 17 Sep 2022 09:01:17 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_23add6c0-cfdb-4bb9-b90f-bf23b83aa6c0_Enabled=true; MSIP_Label_23add6c0-cfdb-4bb9-b90f-bf23b83aa6c0_SetDate=2022-09-17T09:01:14Z; MSIP_Label_23add6c0-cfdb-4bb9-b90f-bf23b83aa6c0_Method=Standard; MSIP_Label_23add6c0-cfdb-4bb9-b90f-bf23b83aa6c0_Name=23add6c0-cfdb-4bb9-b90f-bf23b83aa6c0; MSIP_Label_23add6c0-cfdb-4bb9-b90f-bf23b83aa6c0_SiteId=75e027c9-20d5-47d5-b82f-77d7cd041e8f; MSIP_Label_23add6c0-cfdb-4bb9-b90f-bf23b83aa6c0_ActionId=501e72a3-41f6-43b7-876c-9d0fbd12798a; MSIP_Label_23add6c0-cfdb-4bb9-b90f-bf23b83aa6c0_ContentBits=2 x-ms-publictraffictype: Email x-ms-traffictypediagnostic: AM6PR10MB2197:EE_|DU0PR10MB5704:EE_ x-ms-office365-filtering-correlation-id: e805a026-0968-4eae-3438-08da988b2e6a x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: TlejUJSw56Sy1VAkonC+D6GI+n3S6eskCD+hoFTPeA5+q/QErffbys97yDfky9NgxSP+rpAHXaB3DIQsi5/FlV/thqNjesGDbcdQNRMzPQ5kuiOp7EbJePdvWZjSUAkMOC8imbQv2NwXDA2thNG6trwdZQSVUPZ1DTHfW7FTsy4LeQCdusKTSTjdnSxQeywJWaKcWhy2aQlmL6+xCkvyyBTfnxj0Cq6oODHu9NS9gytrGuJwNK0iqqoHG86kYw5ktMit7guozhnoQNw0YV7ZNAFrhqkFcJWdV82ZhlZ+gLQl/Omw4dKsLrvnbwcISwFVNj1B7N0GCb8VicwGxxkRB3XBG9PNBYFnfKoLcHNGw70l1KdtyFZCyzwz0MJHZkY4cvxj2Cu3rciQrCJFQmX76oehnv1l/nEH/KTwhjD5RkAGSCZrOSPlK6AeWq6sAs0tDEzprYCQv4RRx4DsTwKKGYuffCpwqiHTZfe4p0pDKtuKb03WQj9Ke6D9kc5iP8ofV5pECYmUmZNShb5znE/q5lj7fZve1tMk76gMbbpOnjajfKLGOlHU4InfXqBU+UORn/5hKXWjaZVW3Z1p0tgH2jzMRD4KWgv3SvRDFEW1BP+635g7lpVMrTQDwi+ioaGLKeOxlCtgzHayswUVdekWqWLOOozeoWIQjGg5Tniaz26eGDGTGeg49X/ZvJQjr2t4NcccdpWh+g2kOXUPbwWEEqMasgc610uN+MDrZLsAjOic1O9KdjH8RqS5RxTGE4syAuCisLgaA0XiEOoF0zHVDpCS5HM3bSHOao0HQQfjuXdsDJcc92N0ShK28k9MHGdzpnZqpl8geU/PKBuv10YN5IiAf2Cus//xH1qloQtoQV8= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AM6PR10MB2197.EURPRD10.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230022)(4636009)(136003)(396003)(39860400002)(376002)(366004)(346002)(451199015)(6506007)(7696005)(66476007)(41300700001)(86362001)(33656002)(66446008)(8676002)(64756008)(4326008)(55016003)(76116006)(66946007)(186003)(38070700005)(53546011)(166002)(66556008)(66574015)(21615005)(5660300002)(26005)(52536014)(9686003)(8936002)(83380400001)(2906002)(122000001)(38100700002)(966005)(71200400001)(316002)(54906003)(6916009)(478600001)(460985005);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?4Vg71m8xAQqLugqcPmyxRoZl2JmfT6J7A+O/Bfe37aGlWlX71je1z1Jru2?= =?iso-8859-1?Q?LQ3ZtJOb6HbeIB7CctshxN+ikWmih6mVmU2vC4S+vlY//lpDql8uofB3FB?= =?iso-8859-1?Q?9v64wnu3BfXO00Ix3Z2fGHLtv8nq1Zjh35QSVOsEJn61PTSwWNszTJ+uiL?= =?iso-8859-1?Q?+UTsAAisLayPA/WXy7O/Jb9/92aL4dUs+WAHrARZPJjwITIND9iml/XUCJ?= =?iso-8859-1?Q?PgsGQifnOYCN9FRv3/8iX80yiz7KB3rTwjzi+7tHmf57lK1i4qQ01Lrq03?= =?iso-8859-1?Q?1iaVx+2kEZdUNOLxxYksxql5GakADM2QSG2EdFvvVkDF13XomiZwG6r8H+?= =?iso-8859-1?Q?utcQ8lUJJIh54CzSqq5zfNPKZQcQAzyIcWm8uM0dhaILUuAsKphJjiaa7s?= =?iso-8859-1?Q?ep94B++3+rokhkHu1SxF6L/iggVE0M5Xn9Jjcx1JsvnWRCRbEzMlJvFl0t?= =?iso-8859-1?Q?A+hTLWfghLIC658C53ZIMPZprCCSOaZQOEtzA9yJTZANTuGUlgFcJWTx5B?= =?iso-8859-1?Q?aIy2L6dGIlxYAH+y1/FlgwyPYhmCloI/PHmqbEY5Aca319u9M7vCyyux2r?= =?iso-8859-1?Q?OmxdeYbVJprPX7S/uRBLg9VETx0uxTBMH3cp6/qv/KKJDlS84LOqpFKDqk?= =?iso-8859-1?Q?kZVPf2EvXeQcP3icT2Gp7Sw8zcvMwSB95ktrBm193fH93fzTCLo23dI6jJ?= =?iso-8859-1?Q?zLStPCxFJXQPQAt78LSFqCJi3Am1GdJhhPDB/BTKJCttdwJw96uK5VcFfP?= =?iso-8859-1?Q?Z3UMd8bmlWvt8Y31PZZXGNxkz7v/q4sbOHxZI5NHJl88s6qVW2hLxhyE4c?= =?iso-8859-1?Q?r/lI5Sbof9LpROLhHCmQulpWARufdltw7zg0JsmA0fbP//RHKnX+cPTea8?= =?iso-8859-1?Q?HY5bN5bF7eZES5aa7uQpN6lROpEl65lr1vYhCb3NSvRsuhNoAjaFNVTscu?= =?iso-8859-1?Q?R7Brlmz/RRJUrO9hAx26lFN3gC9cECooyecw1Jl8S3/q0eKfIuNyspYWws?= =?iso-8859-1?Q?BxaPLcwn8vVo4XixVajlWGnbMjzsC8UMvk08/TrFBEXlyrVZp14/ywK6rE?= =?iso-8859-1?Q?P7Y039lYl89+gCOQcL9eas+/z3RJtGge245xIwGr+dhY/bVUSaapWzOcCy?= =?iso-8859-1?Q?y8A+88kUo8n8TWStPEKQlqEhA3qW0lS+p3yVqT2kwxjTUOKZDaZajSg5b+?= =?iso-8859-1?Q?es19vOBn47gNUlyfvrpXuI8Ynw/yBGGTo8DW0hD2aqf2FD0A39fb3KPHsq?= =?iso-8859-1?Q?z5wmfuMus3k0DStoJAFFoOvFC+znYzp+sxLBjBikmAmTMSaRGRfUB0aAMe?= =?iso-8859-1?Q?SlKDNX1/PLSfWiCEFvZwqk87HmV4MT9aY1F4pMdTU5qZhFcwbLzjlMXBcE?= =?iso-8859-1?Q?zUvquwZ5MpqpdgADv5K3S2lW+EA2XQgWEdbtg0bv6atUYfVfMJZ7erpwsc?= =?iso-8859-1?Q?c/wqaAy+mZh4T35A3ymtIMp4xPkmF1/XBT5S/38ik9sCkjccBaUE2ZMBxs?= =?iso-8859-1?Q?RMSUPuhl+daKt6TEv9neSi4p4z1HEEICwdjUScekDQ1bPduuW0t2/Kkt9B?= =?iso-8859-1?Q?3JVhYKIANknmgy2HYUpSX+2reefwF6QLS6adrgwEC/i62/F1vdW2Wywgo1?= =?iso-8859-1?Q?tvgEtVidptbMx5GVh5QJJN9U99P8C3dHLtWr1CH8VL9LnNT3DltXlkRA?= =?iso-8859-1?Q?=3D=3D?= Content-Type: multipart/alternative; boundary="_000_AM6PR10MB2197F43D6BC2C070B3664987814B9AM6PR10MB2197EURP_" MIME-Version: 1.0 X-OriginatorOrg: ST.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM6PR10MB2197.EURPRD10.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: e805a026-0968-4eae-3438-08da988b2e6a X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Sep 2022 09:01:17.2778 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 75e027c9-20d5-47d5-b82f-77d7cd041e8f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: EtLotgaOZz7cNUw8wFUgO/FRYGA2edjoN7OAskUP2IXwD4dzurWtGSGrKCYRjuakDP62cdc3tmPqbY7UjE+1QbIoelhiDNJGcKOOZHG0kmg= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU0PR10MB5704 X-Proofpoint-GUID: pCRagcs0jIOIk9muguOw7K0J11XeWPqx X-Proofpoint-ORIG-GUID: pCRagcs0jIOIk9muguOw7K0J11XeWPqx X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.895,Hydra:6.0.528,FMLib:17.11.122.1 definitions=2022-09-16_14,2022-09-16_01,2022-06-22_01 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 impostorscore=0 mlxlogscore=999 bulkscore=0 spamscore=0 lowpriorityscore=0 clxscore=1011 malwarescore=0 adultscore=0 priorityscore=1501 phishscore=0 suspectscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2209130000 definitions=main-2209170063 X-Spam-Status: No, score=-5.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,HTML_MESSAGE,KAM_LOTSOFHASH,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,SPF_PASS,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: --_000_AM6PR10MB2197F43D6BC2C070B3664987814B9AM6PR10MB2197EURP_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, The patch looks good to me. Thank you Jeff for adding the HAVE_SYSCONF_PAGESIZE logic! One minor question. When HAVE_SYSCONF_PAGESIZE is not set, there would be 2 possible values (12= 8 or 4096). Would it make sense to also have that ifdef part in the sysconf= function? I know that my original patch did not include this, but maybe it= would be beneficial to have sysconf(_SC_PAGESIZE) return 128 when SMALL_ME= MORY is defined and sysconf is not overridden by the application? Kind regards, Torbj=F6rn ST Restricted From: Jeff Johnston Sent: den 16 september 2022 22:14 To: Torbjorn SVENSSON Cc: Jerome Leroux ; newlib@sourceware.org Subject: Re: Malloc: unusable area at the end of the heap section Ok, I am attaching the modified patch after discussing with Torbjorn about the = licensing. Torbjorn, please review and let me know if there are changes you would like, otherwise, I wi= ll push. -- Jeff J. On Wed, Sep 14, 2022 at 4:52 PM Jeff Johnston > wrote: Hi Torbjorn, I took a look at what would be needed to make this more generic. I have a = patch almost ready, but the one issue is that your libc/sys/arm/sysconf.c file does not have a lice= nse. Could you please append a newer version of the file with a license and I will complete the patch for = you to review? I decided to go with a simple HAVE_xxxx macro rather than a configure optio= n so any platform can simply set the flag in configure.host. -- Jeff J. On Tue, Jun 7, 2022 at 12:03 PM Jeff Johnston > wrote: Hi Torbjorn, I think it would be useful. Do you want to modify the patch to be more gen= eric? I am thinking of a var set in configure.host that sets a compile fla= g at the end such as _USE_SYSCONF_FOR_PAGESIZE. Then, the default sysconf.c can be put in the newlib/libc/unix directory. It is = then a straight-forward exercise to add this as an enablement configuration= option. What do you think? -- Jeff J. On Tue, Jun 7, 2022 at 2:18 AM Torbjorn SVENSSON via Newlib > wrote: Hello, A while back, I provided a patch[1] to newlib that would allow the applicat= ion to override the pagesize for malloc, but the patch got stalled. Maybe t= his would be a good time to take another look at the patch and see if it wo= uld actually fix the generic newlib usage or if it's still something that i= s only applicable for small embedded targets. [1] https://ecos.sourceware.org/ml/newlib/current/017616.html Kind regards, Torbj=F6rn > -----Original Message----- > From: Newlib bounces+torbjorn.svensson=3Dst.com@sourceware.org> On Behalf Of Jerome > Leroux > Sent: den 6 juni 2022 23:18 > To: newlib@sourceware.org > Subject: Malloc: unusable area at the end of the heap section > > Hello Newlib developers, > > I am a user of Newlib in a project that runs on an NXP MCU. > I am using MCUXpressoIDE_11.3.0_5180_prc3, which comes with GCC "arm- > none-eabi-gcc.exe (GNU Arm Embedded Toolchain > 9-2020-q2-update) 9.3.1 20200408 (release)" and Newlib 3.3.0. > > I have identified an issue in malloc, and I think the problem is still pr= esent in > the latest version of Newlib. I could > not see any changes in the incriminated code since Newlib 3.3.0. > > I noticed this issue only in the standard malloc implementation and not i= n the > nano-malloc version. > > Here is a description of the problem: > The allocator splits the heap into pages. When a page is full, it increas= es the > heap size by reserving a new page in the > heap section. When reserving a new page, the allocator keeps the page end > address aligned with malloc_getpagesize, which > is set to 4096 by default. If there is not enough space to reserve the fu= ll page, > the allocation fails even if there is > enough space in the heap to allocate the chunk of memory. > Because the issue is related to the heap end address and how the linker > positions the heap, the same sequence of > allocations may lead to different results (failure or success) depending = on the > location of the heap, even if the heap > size is constant. Typically, adding a new C global variable can shift the= start > address of the heap section and cause a > malloc error. > > For example, with a heap section of 4096 bytes (0x1000 bytes): > If the heap section address is 0x20100-0x21100, during the initialization= , the > page end address is set to 0x21000 > (aligned on 4096). We will be able to allocate until the address 0x21000.= After > that, the allocator will try to reserve > a new page, but it will fail because it won't be able to reserve a 4096 b= ytes > page from 0x21000 to 0x22000. The > following allocations will fail. The usable heap size is 3840 bytes (0x21= 000 - > 0x20100) instead of 4096. > If the heap section address is 0x20F00-0x21F00 (same size), with the same > scenario, the usable heap size is 256 bytes > (0x21000 - 0x20F00). > Here are two examples of heap configurations: > https://gist.github.com/jerome- > leroux/759159fbd3e7bb5e189dbceb04636914?permalink_comment_id=3D4191 > 266#gistcomment-4191266 > > I did not dig into the implementation so much. From my understanding, the > problem comes from the usage of > "malloc_getpagesize" (see > https://github.com/bminor/newlib/blob/830a9b707caa5e343b6ffce7fcb2d3c > a97e3259c/newlib/libc/stdlib/_mallocr.c#L198) in > "malloc_extend_top" (probably here > https://github.com/bminor/newlib/blob/830a9b707caa5e343b6ffce7fcb2d3c > a97e3259c/newlib/libc/stdlib/_mallocr.c#L2166). > I can understand it makes sense to keep the pages aligned when running in= a > system that implements virtual memory. > Still, on an MCU, the heap is just a contiguous chunk of memory allocated= at > link time. Furthermore, the heap size is > usually pretty small (a few kilobytes), so potentially wasting 4 KB of me= mory > is unacceptable. Using the default > implementation of "sbrk" documented at > https://sourceware.org/newlib/libc.html#index-sbrk will lead to the > problem. > > I have written a simple example that demonstrates the issue (see > https://gist.github.com/jerome- > leroux/759159fbd3e7bb5e189dbceb04636914 ). To reproduce the problem, > define the macros > HEAP_SECTION_START_SYMBOL and HEAP_SECTION_END_SYMBOL, which > are specific to your environment. Then call the function > "test_malloc()". > > I tried to find someone with the same issue, but I couldn't. The related > commits/discussions I found are: > - > https://github.com/bminor/newlib/commit/4a3d0a5a5d829c05868a34658eb > 45731dbb5112b > - https://stackoverflow.com/questions/39088598/malloc-in-newlib-does-it- > waste-memory-after-one-big-failure-allocation > > Can anyone confirm what I have noticed? > > Thanks. > > -- > Jerome Leroux --_000_AM6PR10MB2197F43D6BC2C070B3664987814B9AM6PR10MB2197EURP_--