From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-120.mimecast.com (us-smtp-delivery-120.mimecast.com [216.205.24.120]) by sourceware.org (Postfix) with ESMTP id 09900385780D for ; Wed, 24 Mar 2021 22:52:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 09900385780D Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12lp2049.outbound.protection.outlook.com [104.47.66.49]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-539-l4Yu3mBVMNO1jVf4uqbXMQ-1; Wed, 24 Mar 2021 18:52:12 -0400 X-MC-Unique: l4Yu3mBVMNO1jVf4uqbXMQ-1 Received: from MN2PR05MB6541.namprd05.prod.outlook.com (2603:10b6:208:df::11) by BLAPR05MB7346.namprd05.prod.outlook.com (2603:10b6:208:285::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3977.14; Wed, 24 Mar 2021 22:52:10 +0000 Received: from MN2PR05MB6541.namprd05.prod.outlook.com ([fe80::896e:1520:f83a:d2d7]) by MN2PR05MB6541.namprd05.prod.outlook.com ([fe80::896e:1520:f83a:d2d7%6]) with mapi id 15.20.3977.024; Wed, 24 Mar 2021 22:52:10 +0000 From: Mike Gulick Subject: Re: GDB memory usage with compressed debug info To: Matt Rice , Christian Biesinger Cc: mgulick@mathworks.com, Reuben Thomas via Gdb References: Message-ID: <23c0c26a-d89f-2cef-e1ca-57558f32924f@mathworks.com> Date: Wed, 24 Mar 2021 18:52:08 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0 In-Reply-To: X-Originating-IP: [146.115.133.179] X-ClientProxiedBy: MN2PR13CA0008.namprd13.prod.outlook.com (2603:10b6:208:160::21) To MN2PR05MB6541.namprd05.prod.outlook.com (2603:10b6:208:df::11) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.1.136] (146.115.133.179) by MN2PR13CA0008.namprd13.prod.outlook.com (2603:10b6:208:160::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3999.14 via Frontend Transport; Wed, 24 Mar 2021 22:52:09 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: e7149f2e-e8f2-4501-d5b2-08d8ef177517 X-MS-TrafficTypeDiagnostic: BLAPR05MB7346: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0 X-Microsoft-Antispam-Message-Info: b5BRtwUkDVSk5LKTFYbQMtER+/FUnKg01cJjOorzhPkq/FCCpPMO9XzILzdRAj8SxD8cS57VkyzXlyBsuGc9XczazGVcEHZsujvUFRBFidSC7UgYzxJsxnu7gfZESEizNx2fNaMvwzxR9QL76z42Tnse6MHIdm/C0PzAagCrKh2MjH/w34b9Sq6POfB0NnHRVR/NF2a2P0YWG8WgS5ThwOY3zZg8uJd4w5tKBtvllpjan1ccMAFlrZ2nn2eXjx7lvGUDNCHqfQBBnenCGEmgvU0gBqmGEC4Ct4rWvJGg301UWaX+IAzYal6QrXuzQPlsZcrDYeW6MGTtwzt6zLcj6pNkQn2uctA4DlT6ynvAnRWswu9I34WaQfPt1SYRkM0xP/Tn3PLhizygS47kG7ZLoB4waDfQyous71904N3z6dmRhE/iHd7BQWnWy8aAnc+v6OPNoPkdZqsXsx7qUSwIh9x9lAWmqUa5lGHV2puEI9Is1CvVQ/D6hsr7CV4iAmir4774HIdtRDpqPT2OKqMQfgekn9UmpHFvkoziB7CFzWmsM1a7OLeJ/CcPEZI3X+r19d68r7utlX/q9H92oKp8zAKO5S/vc0zs9cGv9lvwz/H212FjYOXnXNczyZATIZvwHHCKYzIXO1OGfmmjklz1NINTtQaQkw7IHToylocrNht+9gH3/y4K0xafw45mIn6+9/1wy0jEf3sOmXc+PRB8YJ9PqsGpqAlCdeSTCLsXeHUAmvb1cUSCMRH9iUadDzZMdLVF0x3ofJyabkwUEiMP+UQBTbiF3XeEOe3owbOhtcg= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR05MB6541.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(39860400002)(396003)(346002)(366004)(376002)(16576012)(38100700001)(5660300002)(4326008)(2906002)(6486002)(8936002)(66556008)(26005)(478600001)(86362001)(16526019)(66476007)(956004)(110136005)(36756003)(2616005)(66946007)(31686004)(31696002)(8676002)(316002)(186003)(52116002)(53546011)(43740500002)(45980500001); DIR:OUT; SFP:1101 X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?SzVQS1cwN3E0Y2dPN0tVRGJRRTF2dDZ6TGU0TkZsS2hVYXhJNGlFWjgyWm1o?= =?utf-8?B?UWxlc1JKUDJibFZvSWVuemE4Wkl0dVdTK0dHSSthMVM5SFlENGVHbjFJblpJ?= =?utf-8?B?anp4VkRnMnpadGpCWDg1OXdld1I4KzNtZWwwd2ZIUE4ramR5NUh2K0JKK3FW?= =?utf-8?B?QUxkU3lDd0ZpRXpPSkw5S0Y4YVFVa3V2K0l6RXd4clIxdGw4OEFsdjhKdzBF?= =?utf-8?B?eUM1ODU4OU0xaUxWdkR2dGRJSElvbiszck9vbThuYklPZ2ZheitGU1NycjdU?= =?utf-8?B?VzQ5MjFiUUlOdUpDYitGMUNHRFRoMzc4VkU5V3JvUTBWdkhoTzRMZ0lmblpU?= =?utf-8?B?RDAxMDNtQy9VNHFFYmg5TkpZeHZZV2dTbTF4Y280d1VZRmx3bGhYM3hJSlN2?= =?utf-8?B?SlIyTVRSTmFGSkRIS0tVZm5Qa3c1d2FiQ09zYlNEOVBrV1Y3SmdtSkJRbjc2?= =?utf-8?B?NW9HZHk1bHRwaUF2QmZKeVZ5SVNsN1Y0Qy8wWDZJK2hXSmcvVG9mUDlwMmRw?= =?utf-8?B?aHpMaFNiZ0lhOUpxRVQzQlZydDk5NHlSL0ROMXdHY3EzUlMvc3dZc2RxUkY5?= =?utf-8?B?WDBiN05odFdDMTdSeFVSQTAwai9jUHFSc0N6RXVQKzVmOFAyLzRQYXE4VWpQ?= =?utf-8?B?ZnNNSTM0SFJ0UC9RdlltY0ZhSGFSUk1WQk1OVDNpVGpxcmxwUFZ5bUN2eVpt?= =?utf-8?B?WnJXeWRaalZOdGcrWEwwNnpqU3N5UjZqYU9PeXNtNTNlbEhuNjFtUHU1Umlr?= =?utf-8?B?Q1lYUVpFWWVmbWF0OE1nM3pzbDQ4UlQ4WDBRSXMxRDlPV21idGd2WEpaT3Rs?= =?utf-8?B?bFBQUDk0emxRQ0tEZlpVazJmZ0pBakhOYU9Ga2RsYU5acVQ0dkRJNnZBVjFx?= =?utf-8?B?Nm1SaFVpVUp4aEkrUmNXWUE4Wm1XRW8wNHRlQlVBaXRBQnpiUkhLMDZaTFpJ?= =?utf-8?B?WnE3Z0cwTFQ2dVFuMUVxeUVHaUxkNDRUTStUZ2F1TTIzbW1rWGQzNzY4U0x5?= =?utf-8?B?NjUzMkFMN2NheXRDY3oxWEtsdk9Pek55SVpJc1lNQWZ6TzlQTWYraXFlb1F4?= =?utf-8?B?RjlpaW9XYUlJUFlpTHhiZjZVQU5MYWtqL1FkWU1pZnIwMVJDWDlnMVQ0N015?= =?utf-8?B?S0xPajU0UGMrazYrNHpvdCtjVXNQK2FrcUJtVXFuazl3N1NlSWQ0SWF6OXpo?= =?utf-8?B?MUsyRDNjdlBCWHEzcjNlN05wam1iS2dCR3l2c0RFcDhyVGxQR0xMWXNvdjdk?= =?utf-8?B?QzZ5aUR1d3laeTVNSFVERUd1VE9tSGxrckMrY2hyYzg5c0s5UVI4SlpyT2cz?= =?utf-8?B?VStVMUtoTXpjYlBtV0IzL2U0Qk01a0dFUDRMbFFCakhlb3NobEJTR0hDd3pa?= =?utf-8?B?KzFiczY4bG83K0dicnA0TS80NnZCUFkweUVoUmt3ZXZJWktFR0tuMlgvblpi?= =?utf-8?B?WUdDbjNrQ21sVWZoY1daK3kyQTlLY29kZ1NZWHE3YmFJQ2V6N0hHRG5wRVRK?= =?utf-8?B?VVoxUFg3a1N3bzJVMjcwdS9hRVRpa29pUnB4MGxMNjhHT0M4OGVGV2F4VzFW?= =?utf-8?B?TGhJQTNWbndZckNYdktOdGxESk9NcVMzZURWdTY2bXExTFp3WTlYK2xCK0hw?= =?utf-8?B?M0JDNjB2OEVCYkNzMXFka2RWYmY2ZW9TMWQrUXlGZGUybmxRNUxMSXB4bFd4?= =?utf-8?B?THJ1aTVMUTFrc1dnS3JVQUV5UlV5dzJpZEQ1c25NdWFMNVRLaStuemhFcjYr?= =?utf-8?Q?JLNHBEcCWJB3aYVZaOTkWD9P5r57jNVIo6X74TO?= X-OriginatorOrg: mathworks.com X-MS-Exchange-CrossTenant-Network-Message-Id: e7149f2e-e8f2-4501-d5b2-08d8ef177517 X-MS-Exchange-CrossTenant-AuthSource: MN2PR05MB6541.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Mar 2021 22:52:10.2166 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 99dd3a11-4348-4468-9bdd-e5072b1dc1e6 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: fBhY6Vf6IAovtA7mg/hfp8e+U4dqyhen/iaGDjSCzHHWjc8uZg820NkJTdFwsA33HIKYL2Al3yF85f+pVMuDeg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLAPR05MB7346 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: mathworks.com Content-Type: text/plain; charset=UTF-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, MSGID_FROM_MTA_HEADER, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2021 22:52:17 -0000 On 3/24/21 3:59 PM, Matt Rice wrote: > On Mon, Mar 22, 2021 at 6:16 PM Christian Biesinger via Gdb wrote: >=20 >> On Thu, Mar 18, 2021 at 7:38 PM Mike Gulick via Gdb >> wrote: >>> >>> On 3/16/21 2:40 PM, Mike Gulick wrote: >>>> Hi, >>>> >>>> I'm observing that GDB memory usage is much higher when I have debug >>>> info compressed with 'objcopy --compress-debug-sections'. In a large >>>> C++ application, I see the instance with uncompressed debug info use >>>> 46GB VIRTUAL memory and 11GB RSS, and the instance with compressed deb= ug >>>> info is using 46GB VIRTUAL memory and 42GB RSS. In case it matters, t= he >>>> debug info is separated from the original binary into its own file. >>>> >>>> It seems like GDB must load the full uncompressed debug info into memo= ry >>>> when the underlying files are compressed? >>>> >>>> I'm currently using GDB 9.2. I checked the 10.1 NEWS and didn't see >>>> anything that looked like it would have changed this result, but I'm >>>> happy to give it a try if you think it might help. >>>> >>>> Is there any chance this could be improved with a patch to GDB, or is >>>> this just the nature of compressed debug data? >>>> >>>> Also, FYI, the NEWS link for the GDB 10.1 release on the GDB home page >>>> points to the NEWS file for the 9.1 release. >>>> >>>> Thanks! >>>> >>>> -Mike >>> >>> I should add that this high memory usage only occurs when there is a >>> FILE:LINENUM breakpoint set (or pending). I can run the application >>> being debugged, observe that GDB's memory usage is around 11 or 12 GB, >>> then run 'b foobar.cpp:123', and the GDB memory usage will climb up to >>> 42 GB. Interesting that symbolic breakpoints don't trigger this high >>> memory usage, but line-based breakpoints do. Does this seem expected? >> >> I'm guessing that this is due to parsing full debug info ("expanding >> psymtabs") which is not necessary for symbolic breakpoints, which can >> rely on minsyms or maybe psymtabs. Have you tried using a heap >> profiler to see where the memory usage comes from? >> >=20 > It could possibly narrow it down if the behavior of FILE:label breakpoint= s > differ, though I'm not sure what to expect exactly. >=20 I've never used a heap profiler before, but I tried running a debug=20 build of GDB 10.1 with heap profiling via an LD_PRELOAD of the tcmalloc=20 library (https://gperftools.github.io/gperftools/heapprofile.html).=20 This showed that the stack which was doing the vast majority of the=20 allocations was this: bfd_malloc /gdb-10.1/bfd/libbfd.c:275 bfd_get_full_section_contents /gdb-10.1/bfd/compress.c:320 gdb_bfd_map_section /gdb-10.1/gdb/gdb_bfd.c:724 dwarf2_section_info::read /gdb-10.1/gdb/dwarf2/section.c:161 cutu_reader::cutu_reader /gdb-10.1/gdb/dwarf2/read.c:7339 dw2_get_file_names /gdb-10.1/gdb/dwarf2/read.c:3287 dw2_map_symtabs_matching_filename /gdb-10.1/gdb/dwarf2/read.c:3399 iterate_over_symtabs /gdb-10.1/gdb/symtab.c:558 collect_symtabs_from_filename /gdb-10.1/gdb/linespec.c:3797 symtabs_from_filename /gdb-10.1/gdb/linespec.c:3817 parse_linespec /gdb-10.1/gdb/linespec.c:2613 event_location_to_sals /gdb-10.1/gdb/linespec.c:3150 decode_line_full /gdb-10.1/gdb/linespec.c:3230 parse_breakpoint_sals /gdb-10.1/gdb/breakpoint.c:9037 create_sals_from_location_default /gdb-10.1/gdb/breakpoint.c:13733 bkpt_create_sals_from_location /gdb-10.1/gdb/breakpoint.c:12534 create_breakpoint /gdb-10.1/gdb/breakpoint.c:9253 break_command_1 /gdb-10.1/gdb/breakpoint.c:9411 break_command /gdb-10.1/gdb/breakpoint.c:9482 do_const_cfunc /gdb-10.1/gdb/cli/cli-decode.c:95 cmd_func /gdb-10.1/gdb/cli/cli-decode.c:2181 execute_command /gdb-10.1/gdb/top.c:668 catch_command_errors /gdb-10.1/gdb/main.c:457 captured_main_1 /gdb-10.1/gdb/main.c:1218 captured_main /gdb-10.1/gdb/main.c:1243 I also tried setting a breakpoint using FILE:function style, and the=20 memory usage was pretty much equivalent to FILE:LINENUM. This would=20 imply (as would the above stack trace) that matching the file name=20 causes the full debug info to be read in. Thanks, Mike