From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70081.outbound.protection.outlook.com [40.107.7.81]) by sourceware.org (Postfix) with ESMTPS id 0F288385840B for ; Thu, 3 Feb 2022 00:44:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0F288385840B Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=fer.hr Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=fer.hr ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dI9aJOX4BUJMyFwBpX+ic6LnBpnFv0GttMIHmx25gVBCMrPJqQsDmJ/X1BnqPQS7feJdWsFP84XqZTWIcxByotNCj9O/nlEfr9hlfDcsSryslrgJTI5NMg53KX8cyx/8SwBFR7j8biYsMZIaQwLnaHhze5C+jspJMSyjWDQUgii7twLa5Xwe1Td2249Ncol+b7SInIKEWA7yIpP/qwfgDzK9OXdsGjCXSYOw9UpN1c+NX+Zpw5i0j5/VBlPvgp/vh9ceOolD6eEKvNw9pZAuVZri78bSZXEQ5JN3PEqfPVQlDfQh5bZfYa9UOmBbtYyV+fQlDMkH/LsWtt96A05TWw== 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=gwEycni5fL95eCSxTZrzbS/mNIrWk/8t3dYEvHfQbfI=; b=lFCv8aJo+KZiV/6tJOczqEueEcw+vKBPkPHjvQhMuyOqsnZz/jzP+WSjS0y+bF47NqLAtjJwGP+rSCGMs31gM+urkOIzgPqAiVZANii5oa66bLBOq9JNxORCAg+fnuYAHm3078bIT9OH4twEHJr4KmsDYF5P0tzE0YTBPpb006678tWJrQR7F8RdMzuT3t8gD0R7hxeyJfMFm9RvRkSTmRzqXbn6cMQUVZfxjt+MJ/rqZB8VAQYLbgTzKvG6hDCMs/gNewHm9INn22si/Ux+KJtLEvJ/ISf27StTP0KlVZyUj9x9x+6Wpsm2tqIycmo2ah61V1l8NKU4DVbigXDfXw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ferhr.onmicrosoft.com; s=selector2-ferhr-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gwEycni5fL95eCSxTZrzbS/mNIrWk/8t3dYEvHfQbfI=; b=GHQ7maje3fCHQhZCNhzazUQw4YfcK3aiPElUMo8tG20q7INALsd1j2JvvpfihREERYkJAgMHXrLMGYQTdwrLJOAVimG9nMllw9HXBU3pv1aT2V/jEx6spp+raIt/qg0JTCsZ16rym4zmOa0pfeXLpAnij42Vhhu3LquYdaKqwhM= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=fer.hr; Received: from AM4PR08MB2916.eurprd08.prod.outlook.com (2603:10a6:205:e::29) by VI1PR0802MB2256.eurprd08.prod.outlook.com (2603:10a6:800:9e::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4930.19; Thu, 3 Feb 2022 00:44:25 +0000 Received: from AM4PR08MB2916.eurprd08.prod.outlook.com ([fe80::684b:73d:8379:f3cf]) by AM4PR08MB2916.eurprd08.prod.outlook.com ([fe80::684b:73d:8379:f3cf%6]) with mapi id 15.20.4951.012; Thu, 3 Feb 2022 00:44:25 +0000 X-Gm-Message-State: AOAM530yorLNIbjm70v2PVk5ZIdv5NW9XKbXn/Nf9iFjSzl5lFQi03xJ 52kNZgzQTYcK8hHDB+vuQ6uEyE03KLj0ixrW7m0= X-Google-Smtp-Source: ABdhPJwoe1jB5Ga0FFeG5RSPSaEVKuLIWGe9mLoiAfEoPFWPDcd6XnMmLrCivjLskvi2Qtbz8boDc4z8vLp+KXQ4CKc= X-Received: by 2002:a1c:4645:: with SMTP id t66mr7915640wma.39.1643849064046; Wed, 02 Feb 2022 16:44:24 -0800 (PST) From: =?UTF-8?B?SnVyYWogT3LFoXVsacSH?= Date: Thu, 3 Feb 2022 01:43:48 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Incorrect unwind when throwing exceptions - possible cause? To: gcc-help@gcc.gnu.org Content-Type: text/plain; charset="UTF-8" X-ClientProxiedBy: AM0PR02CA0112.eurprd02.prod.outlook.com (2603:10a6:20b:28c::9) To AM4PR08MB2916.eurprd08.prod.outlook.com (2603:10a6:205:e::29) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 78d74be9-53e1-4053-284f-08d9e6ae539e X-MS-TrafficTypeDiagnostic: VI1PR0802MB2256:EE_ X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:8273; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: PUVAYML6lB+5vR1h/WBRiHlEznGfZICzUr6Wkg+ZpkKHxIBBSAut6G0n9yKkqCB7NHz1AOMNYdcpC9M/V65e42+rxiVR9ca1xRAXoAmEqkJ1TCfnAqEm/acsEIpwnnpimp62HG2pZ7CDgq9BAWadLHwHkqvvNIDZIWHjXxJYdoFxR2syDKGk4NrxzVAHOBdZ1cQjPacXcDXU1G0A97zSU8wQ2ZrOVh7ZbaaFSEDKqhAXTDJwMuAUdnAIyG2spMYYjTKC0ZukMWDq32sHDFZ6hb+e9TGGefMYBtZc+HhimrGITbi9P78ls2V0BZuVFQKqG3nOcG6/Ap8tJTwSjJkXTxZZKCbz9v68r9FKtXFLBb0IgrXhVydLOupFl/BRqgDhZ5KFbzeWxSHK/sMLg5qL0dDwstzLNKSqrZf3RYyCKMmLWSfViuhFsaohQASz0B6DNp7t19DpjdvFLlDOWN8ukOLMpPA85krrajWTK6UAefCitps4gMeXFF/etBqVbL7hBuDTyB/lwAjwWhmRUVYYjHB3foqa69KVBaZXw0wjuLBagWrrN1behEHz4AscpTm40NxJWh01z+HyvYEQcb2dGUl/13KVBOLlJ5bsmQLtgsMD0Fb+zbLfCKCfB9JDsxAMSYeJJrd4aFA9jtGnnvvlRsrMM+k6fTJVbgJ3UtsZTnCMO9LaKs6sN0ZQJ52vWQi8KK64a8Q7eU9aGhT5vzk59g== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM4PR08MB2916.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(366004)(786003)(86362001)(2906002)(316002)(55446002)(6916009)(8936002)(66556008)(66946007)(66476007)(8676002)(6486002)(38350700002)(508600001)(83380400001)(85182001)(55236004)(26005)(6666004)(9686003)(6506007)(6512007)(186003)(5660300002)(85202003)(38100700002)(52116002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?bDRKNmkwM2JyUyticG8vTENNc24wZ3VDazdsRjBEKzI5NitpREowVlI4RkpI?= =?utf-8?B?aDVwdDBNMVpkSWJqU2crQi9ja3c0V0lGZGZiYVVvT1prZzJFbkhZNGFMSkEy?= =?utf-8?B?cGNrSzk1amd1ZitGTWdWcE9xbGNEWjNsTCtIaUFlT3ZVMENtek1LWEFkSXEy?= =?utf-8?B?VUk0QS9ibEl4WithYjVpWjVCbm1JL3dFQ1BHY3JJRGhTeDBjSDc2QTIzek0v?= =?utf-8?B?WEJKZGZoeFdBZEZpNndJMi80VFFSNXRwKytVRlF2eXp6dEtBeDZqckV5YnAx?= =?utf-8?B?RTlxekU5eWpCZFRwZFUvWStQanFUaUxGYjdZeEtCTGR6c0w4NDdZeHpLQlkx?= =?utf-8?B?U3ZISkt4R1BKRHFCMTFPSG9BK2lEeStYazU4ZGhQTjJCNVAzbUVqN1lBMWpB?= =?utf-8?B?aTFUQjhuYU9DZCtDZ2NpbDhvSEx6K1dDNm84bXhKQU42R0dXUVN2eW5EM0tD?= =?utf-8?B?UzhLQnQ0VVZFRjk2YnMzTzBEdGdWQzFXaFdMV2dOYUdFeEE4enNPamJDbzFu?= =?utf-8?B?alIvcEpBN3VvQi9kdEtraXpBTm5HeFRxdU1pYzFSSmxHK3h6VVFCTzhzZ2s0?= =?utf-8?B?ZWVVMlVFU2NoYXNFbXYrSW92R3BoYjVKSzVZcnV3ZUxscHNScnhQWkNWeS9x?= =?utf-8?B?TEsxTHI5bFN2M2FVUFFnSG1TUVIzUFRPLzNOdFpldEZkdlZRNWhaelcxdlp5?= =?utf-8?B?aXdYR3g3akpkVmdQdnVZS003NkREYzRHZXA4SG5rSzJGS1VXaDA1Rmd2TXp3?= =?utf-8?B?Umx3SjdCa3RTeFR1NW1yQUJLMmRTejFlSUFtZlA2Q0hRbm5EQkZaeFJJK1Qw?= =?utf-8?B?SVR0VTBzWnk4YWQvL05XNys4NEJGanRWOFpNM0JXMmg2OXRJaHZoVURKZDZM?= =?utf-8?B?cXVIUUROSlZTZ1Z1ZlZyVW9OZ2RqaWl2QjgrUWJ2dmlsMWRzN2dZTFFWTmJY?= =?utf-8?B?aVVYWnFaN2tXNkhXMmNNY1VrcHB4ZFNZK25wbnVNK2dPdEE2TnZMSk9HUGcw?= =?utf-8?B?NkVKMXJZY2x2dXpOQUZURVRJcmYxWEUwY1E4WUMxek14SSs1Z2ZHTUV5UU1V?= =?utf-8?B?eU5RV0NSTGM0SWFrME5uU3dQeVBUV0E3ZlhzQWRydkNYTExjbjFhdlFUTkg3?= =?utf-8?B?eTlzUC9nZ0FiOWlMUjhoTFJSNkEvVTRtMDM3YW1FblpSRHpHQWk3NWUxTWZo?= =?utf-8?B?RlVpK0Vkc2xmbGJsejdmNEhiRVdIM1ZYR3R1blNHZVdnYzhZY0dENjM3eHE3?= =?utf-8?B?eWdWV3FrMmtuQmwwbEtkaVd3R1pwYktnbDgxSTVodUtlZW1RbWZ0amlrRlps?= =?utf-8?B?a0tLUlJyVTcxZytxM25maXZ4QVZhTE8wRmU0NEJ2V3IyWDFWSDlTY2xjZ1BL?= =?utf-8?B?RzJUR0xybVpXbm4rTUVTSE9WR052S3dDRlBFQkE5OTk0YTdKUTkzMGtUMGpZ?= =?utf-8?B?RERpWmh2c295YVdkM0tISFhCUHJDQ2VJUUptakMyekwzb1hyc00wOG5vdXI2?= =?utf-8?B?dUxoN3VsWmJYb3k3bmJMUGVleXUycXZiM3p6RldaVkNzYlJDN2tFL0xlcDg5?= =?utf-8?B?dDZlc1BQNjFLM1B5TWxZVXhScUQwR2hKT2F0SElYZWhKdjBUeVN3WVRkL0Vr?= =?utf-8?B?UllBTnFvY1NuNFh5a3pONkNFWVlTdURkVzFWVjIxTnpvN21tTytKOGQ3TDEv?= =?utf-8?B?VktkK0xYRGpZdjRzUFF4ZzFRRHh1WEhkQThXSkNRYWROUGdnZzltOHFZQ2FF?= =?utf-8?B?Q05TRy9lSEF6dk8wOFRxUWlkbVNYQkkrczgrUlFtSkFOQlMyODBJb05La3BT?= =?utf-8?B?TjhwTFBpTzF4RHNuTkdEQlJXc1RpRy9ucktPQmE1ekw2aFVHWGN2VEt6K3NE?= =?utf-8?B?amx5cldTeVdEMGtTU1Z6dmlQclB2QXdHN2hUcTBBSi9BcXhVUnFJdm1UQnJU?= =?utf-8?B?eGU0OS90Z2JsRlM4TmFNdkxLcHVETXB0RVltZWtZb1duZzBQeHJ0TEkrbWEy?= =?utf-8?B?b25vUnhaY0hmaG52eUtsMXozZFdXYzNjVGRNTXR3N25KbWVvaUx4cnNJcnNp?= =?utf-8?B?dkFZSnBmNnAybVNXNEJhRXlkV0VhMU5nVUtpR21zZWl0MkNTbVhxVklDOHlk?= =?utf-8?Q?096Y=3D?= X-OriginatorOrg: fer.hr X-MS-Exchange-CrossTenant-Network-Message-Id: 78d74be9-53e1-4053-284f-08d9e6ae539e X-MS-Exchange-CrossTenant-AuthSource: AM4PR08MB2916.eurprd08.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Feb 2022 00:44:25.2613 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: ca71eddc-cc7b-4e5b-95bd-55b658e696be X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: bgMLOmC3XHDOjQE+7NUd0oruYWLxnTiWw5JdARDvlrqcGxJGV/fKq/DsQs+X4BzG X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0802MB2256 X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_PASS, SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-help@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-help mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2022 00:44:31 -0000 I have a hair-tearing problem with x86_64 gcc 9.3.0 (Ubuntu 20.04), -O2 and the following "minimal" example (the real minimal example also links in a bunch of 3rd party libraries and is a part of a big project, so I can't really provide a minimal example, but I slimmed it down to basically this): class Application() { public: Application(int argc, char **argv) {} int process() { if (argc > 1) { throw std::runtime_error("Exception"); } // do some processing here return 0; } int main(int argc, char **argv) { Application app(argc, argv); int result = 0; try { result = app.process(); } catch (const std::exception &e) { result = 1; puts(e.what()); } return result; } I get crashes if I throw and there's some more core after the if() in process(). This is an excerpt of how .eh_frame looks like when it works (90% code in process() commented out): 00014c84 000000000000002c 00000000 CIE Version: 1 Augmentation: "zPLR" Code alignment factor: 1 Data alignment factor: -8 Return address column: 16 Augmentation data: 9b 49 4f 3c 00 1b 1b DW_CFA_def_cfa: r7 (rsp) ofs 8 DW_CFA_offset: r16 (rip) at cfa-8 DW_CFA_def_cfa: r6 (rbp) ofs 16 DW_CFA_offset: r3 (rbx) at cfa-56 DW_CFA_offset: r6 (rbp) at cfa-16 DW_CFA_offset: r12 (r12) at cfa-48 DW_CFA_offset: r13 (r13) at cfa-40 DW_CFA_offset: r14 (r14) at cfa-32 DW_CFA_offset: r15 (r15) at cfa-24 DW_CFA_nop DW_CFA_nop DW_CFA_nop 00014cb4 0000000000000014 00000034 FDE cie=00014c84 pc=000000000025081e..00000000002508d6 Augmentation data: d4 7e 20 00 DW_CFA_nop DW_CFA_nop DW_CFA_nop However, if I put just a bit more stuff inside process() after that throwing if(), gcc changes the process function prologue a bit and the unwind table looks like this: 0001ce38 0000000000000034 00013428 FDE cie=00009a14 pc=0000000000252534..0000000000256376 Augmentation data: ab 34 20 00 DW_CFA_def_cfa_expression (DW_OP_breg6 (rbp): -40; DW_OP_deref) DW_CFA_expression: r3 (rbx) (DW_OP_breg6 (rbp): -48) DW_CFA_expression: r6 (rbp) (DW_OP_breg6 (rbp): 0) DW_CFA_expression: r12 (r12) (DW_OP_breg6 (rbp): -32) DW_CFA_expression: r13 (r13) (DW_OP_breg6 (rbp): -24) DW_CFA_expression: r14 (r14) (DW_OP_breg6 (rbp): -16) DW_CFA_expression: r15 (r15) (DW_OP_breg6 (rbp): -8) So it basically references everything against rbp instead of against the cfa, great. Here are the libunwind debug prints. Notice how after processing the expression OP_breg(r6,0x0), thus calculating the new value for r6 (rbp) by dereferencing itself with offset zero, the change is reflected in the calculations for subsequent registers r12-r15 which are wrong. `apply_reg_state` in libunwind writes the new address for the value of r6. However, the offsets for r12-r15 are supposed to be calculated against the inner stack frame's value of rbp (0x7fffffffca70), not against the new one (0x7fffffffcab0)! >_ULx86_64_reuse_frame: reuse frame ip=0x5555557a9d46 cfa=0x7fffffff6cc0 format=0 addr=0x0 offset=+0 >_ULx86_64_dwarf_eval_expr: len=3, pushing cfa=0x7fffffff6cc0 >_ULx86_64_dwarf_eval_expr: OP_breg(r6,0xffffffffffffffd8) >access_mem: mem[00007fffffff6c90] -> 7fffffffca70 >_ULx86_64_dwarf_eval_expr: OP_deref >_ULx86_64_dwarf_eval_expr: final value = 0x7fffffffca90 >_ULx86_64_dwarf_eval_expr: len=2, pushing cfa=0x7fffffff6cc0 >_ULx86_64_dwarf_eval_expr: OP_breg(r6,0xffffffffffffffd0) >access_mem: mem[00007fffffff6c90] -> 7fffffffca70 >_ULx86_64_dwarf_eval_expr: final value = 0x7fffffffca40 >_ULx86_64_dwarf_eval_expr: len=2, pushing cfa=0x7fffffff6cc0 >_ULx86_64_dwarf_eval_expr: OP_breg(r6,0x0) >access_mem: mem[00007fffffff6c90] -> 7fffffffca70 >_ULx86_64_dwarf_eval_expr: final value = 0x7fffffffca70 >_ULx86_64_dwarf_eval_expr: len=2, pushing cfa=0x7fffffff6cc0 >_ULx86_64_dwarf_eval_expr: OP_breg(r6,0xffffffffffffffe0) >access_mem: mem[00007fffffffca70] -> 7fffffffcab0 >_ULx86_64_dwarf_eval_expr: final value = 0x7fffffffca90 >_ULx86_64_dwarf_eval_expr: len=2, pushing cfa=0x7fffffff6cc0 >_ULx86_64_dwarf_eval_expr: OP_breg(r6,0xffffffffffffffe8) >access_mem: mem[00007fffffffca70] -> 7fffffffcab0 >_ULx86_64_dwarf_eval_expr: final value = 0x7fffffffca98 >_ULx86_64_dwarf_eval_expr: len=2, pushing cfa=0x7fffffff6cc0 >_ULx86_64_dwarf_eval_expr: OP_breg(r6,0xfffffffffffffff0) >access_mem: mem[00007fffffffca70] -> 7fffffffcab0 >_ULx86_64_dwarf_eval_expr: final value = 0x7fffffffcaa0 >_ULx86_64_dwarf_eval_expr: len=2, pushing cfa=0x7fffffff6cc0 >_ULx86_64_dwarf_eval_expr: OP_breg(r6,0xfffffffffffffff8) >access_mem: mem[00007fffffffca70] -> 7fffffffcab0 >_ULx86_64_dwarf_eval_expr: final value = 0x7fffffffcaa8 >access_mem: mem[00007fffffffca88] -> 5555558b67a9 >_ULx86_64_dwarf_step: returning 1 >_ULx86_64_step: returning 1 >_ULx86_64_dwarf_find_proc_info: looking for IP=0x5555558b67a8 >_ULx86_64_dwarf_callback: checking , base=0x555555554000) >_ULx86_64_dwarf_callback: found table `': segbase=0x555557215230, len=57926, gp=0x5555576567e8, table_data=0x55555721523c >lookup: e->start_ip_offset = fffffffffebc5730 ........... >lookup: e->start_ip_offset = fffffffffe6a1410 >_ULx86_64_dwarf_search_unwind_table: ip=0x5555558b67a8, start_ip=0xfffffffffe6a1410 >_ULx86_64_dwarf_search_unwind_table: e->fde_offset = 8e0b0, segbase = 555557215230, debug_frame_base = 0, fde_addr = 5555572a32e0 >_ULx86_64_dwarf_extract_proc_info_from_fde: FDE @ 0x5555572a32e0 >_ULx86_64_dwarf_extract_proc_info_from_fde: looking for CIE at address 55555728fe84 >parse_cie: CIE parsed OK, augmentation = "zPLR", handler=0x7fffeeaf3a80 >_ULx86_64_dwarf_extract_proc_info_from_fde: FDE covers IP 0x5555558b6640-0x5555558b6867, LSDA=0x5555574a67ec >_ULx86_64_fetch_frame: fetch frame ip=0x5555558b67a9 cfa=0x7fffffffca90 format=0 >access_mem: mem[00007fffffffca88] <- 5555558b67e9 >_ULx86_64_resume: (cursor=0x7fffffff6870) >establish_machine_state: copying out cursor state >establish_machine_state: copying RBP 6 >access_mem: mem[00007fffffffca70] -> 7fffffffcab0 >access_reg: RBP <- 0x00007fffffffcab0 >establish_machine_state: copying RSP 7 >access_reg: RSP <- 0x00007fffffffca90 >establish_machine_state: copying R8 8 >access_mem: mem[00007fffffff64c8] -> 555557ced700 ... All of these are wrong and cause a crash after landing in the exception handler in main(): >access_reg: R12 <- 0x73746e6f662f6269 >establish_machine_state: copying R13 13 >access_mem: mem[00007fffffffca98] -> 257c32600 >access_reg: R13 <- 0x0000000257c32600 >establish_machine_state: copying R14 14 >access_mem: mem[00007fffffffcaa0] -> 555557c325d0 >access_reg: R14 <- 0x0000555557c325d0 >establish_machine_state: copying R15 15 >access_mem: mem[00007fffffffcaa8] -> 17ebc2371241f >access_reg: R15 <- 0x00017ebc2371241f >establish_machine_state: copying RIP 16 >access_mem: mem[00007fffffffca88] -> 5555558b67e9 >access_reg: RIP <- 0x00005555558b67e9 Does anyone have any ideas? What could be causing this? I'm tearing my hair out. Thanks a lot!