From nobody Sun Sep 24 20:16:37 2023 X-Original-To: ports-bugs@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Rty2Y5d7qz4vP9T for ; Sun, 24 Sep 2023 20:16:37 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Rty2Y1jmlz4N5j for ; Sun, 24 Sep 2023 20:16:37 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1695586597; a=rsa-sha256; cv=none; b=RA+LhVTVp5kJJXcpYMzZdP55P3SdSGIYvenk1XKaj/drGjL5QY3JTirgmN7T21BkWKtZDt j7mxxfnSreCZMnvL+2vh5hSToDxMhT7YUhKwWmnre7pivtWHqGLMrgw70wc3FkeyZjeMxg AU8pu/5kfEZ636U9WWjAl06kE3fKDjtCI2sgHOkxfS77Kkx1ZpKtrJL5yr0dEHLNK0D8wy y5scO4EIiwE2debGu/2mJldTqv5bbQVvlhulLmMChaKKLbp/0AJbtANzcZintKaUpjhx1W FxjE3B0b1oZY/IGg0C+2Ajt1ALDuRhHRSWJ8h6BfDf+TsA4SeJOjpI6nbG6+Lg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1695586597; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=kjGDC0CF9qAIZjCFeKFoDxrQGyLQlKDK6f+sMHhddqc=; b=wb1x7EFJTXtNXPor+mXW9jN8dqpxLtO3FUECw1zlXF3b/z0XpxYZEdA3OzW/U86iO4q2K+ Sep3F/oOY0cHBH1sAZs2AYqlwEaN/7JkPMeYD5ASzlKte1EDBLmZUQe+9PQsoNvV/nZmZx sIuk+eOOlUaPll6pMhnFEDxDFrQc+2/efnUlUKpIeKSllcNj+26ViGUJaOxBcDVw8+2WLz cPzEXwsxhaHm5Uh1LPKadBefXIKQ3KvWUXXHiJW+NKBTtsu+SUTpLvbgZLBy6zcWFGW+ys 31zdrj/55NZ0A7PaSw6wFVTEM7XeoiWB8JURrdya3m0xT29Mw1fI1t5zrIulXQ== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4Rty2Y0h8Wz119s for ; Sun, 24 Sep 2023 20:16:37 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 38OKGb9d069827 for ; Sun, 24 Sep 2023 20:16:37 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 38OKGbK7069826 for ports-bugs@FreeBSD.org; Sun, 24 Sep 2023 20:16:37 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: ports-bugs@FreeBSD.org Subject: [Bug 273688] sysutils/pstack: does not work with Valgrind Date: Sun, 24 Sep 2023 20:16:37 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: pjfloyd@wanadoo.fr X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: ports-bugs@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Ports bug reports List-Archive: https://lists.freebsd.org/archives/freebsd-ports-bugs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports-bugs@freebsd.org X-BeenThere: freebsd-ports-bugs@freebsd.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D273688 --- Comment #3 from Paul Floyd --- procReadThread() is what I meant (gdb) info frame Stack level 0, frame at 0x1002ca9d90: rip =3D 0x381a03a6 in vgModuleLocal_do_syscall_for_client_WRK (m_syswrap/syscall-amd64-freebsd.S:144); saved rip =3D 0x3819f27a called by frame at 0x1002ca9ea0 source language asm. Arglist at 0x1002ca9d80, args:=20 Locals at 0x1002ca9d80, Previous frame's sp is 0x1002ca9d90 Saved registers: rbp at 0x1002ca9d80, rip at 0x1002ca9d88 procReadThread breaks from the first pass through the loop. Here's a printf that I added DEBUG: procReadThread bp 1002024f20 <=3D frame->bp 1002ca9d80 Back over in gdb current rbp: (gdb) p $rbp $5 =3D (void *) 0x1002ca9fa0 (gdb) info frame 0 Stack frame at 0x1002ca9d90: rip =3D 0x381a03a6 in vgModuleLocal_do_syscall_for_client_WRK (m_syswrap/syscall-amd64-freebsd.S:144); saved rip =3D 0x3819f27a called by frame at 0x1002ca9ea0 source language asm. Arglist at 0x1002ca9d80, args:=20 Locals at 0x1002ca9d80, Previous frame's sp is 0x1002ca9d90 Saved registers: rbp at 0x1002ca9d80, rip at 0x1002ca9d88 (gdb) info frame 1 Stack frame at 0x1002ca9ea0: rip =3D 0x3819f27a in do_syscall_for_client (m_syswrap/syswrap-main.c:368); saved rip =3D 0x3819b150 inlined into frame 2, caller of frame at 0x1002ca9d90 source language c. Arglist at unknown address. Locals at unknown address, Previous frame's sp is 0x1002ca9d90 Saved registers: rbp at 0x1002ca9d80, rip at 0x1002ca9d88 (gdb) info frame 3 Stack frame at 0x1002ca9f10: rip =3D 0x3819b150 in handle_syscall (m_scheduler/scheduler.c:1206); saved= rip =3D 0x38199223 called by frame at 0x1002ca9fb0, caller of frame at 0x1002ca9ea0 source language c. Arglist at 0x1002ca9ea0, args: tid=3Dtid@entry=3D1, trc=3Dtrc@entry=3D73 Locals at 0x1002ca9ea0, Previous frame's sp is 0x1002ca9f10 Saved registers: rbx at 0x1002ca9ef0, rbp at 0x1002ca9f00, r14 at 0x1002ca9ef8, rip at 0x1002ca9f08 I'm beginning to wonder if the saved $rbps aren't just nonsense and whether= gdb and lldb are getting their stack traces from debuginfo. Valgrind is a bit of a monster. On startup (it's own _start in assembler) it allocates its own small bootst= rap stack of 1M. Once it has done all its initialization it allocates another s= tack with guard pages and does a stack transfer to that stack via a mov to rsp t= hen a ret. The new stack appears from then on as the bottom of the callstack. On top of that, the callstack that I've been looking at consists of assembler funcion inlined C function C function called via longjmp then "normal" C functions up to the re-rooted bottom of callstack. It looks like the strange $rbp happens after the longjmp. --=20 You are receiving this mail because: You are the assignee for the bug.=