From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 24D7D386F46F; Thu, 21 Jan 2021 13:48:45 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 24D7D386F46F From: "carlos at redhat dot com" To: glibc-bugs@sourceware.org Subject: [Bug libc/27216] Illegally written memory chunk address and its value is not getting printed in core file Date: Thu, 21 Jan 2021 13:48:44 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: libc X-Bugzilla-Version: 2.27 X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: carlos at redhat dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: 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: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: glibc-bugs@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Glibc-bugs mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2021 13:48:45 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D27216 --- Comment #4 from Carlos O'Donell --- (In reply to Akash Hadke from comment #3) > To improve the tracing in case of production issues. > We need traces from the production issues and its too complex to run the > valgrind at least in production cases. >=20 > I have suggested a patch for this. > http://patchwork.sourceware.org/project/glibc/patch/ > CAK0fB4M6pXPL9D1aL8TcpFGZDvjqoJrv93N_hDO26XHkVAkwAw@mail.gmail.com/ You are looking for increased observability in a production application. You patch makes performance worse for every application in the world using glibc malloc. This is not a tradeoff that everyone else is going to agree is good for the= ir use cases. You really need to use valgrind in a non-produciton reproducer of your prob= lem. =3D=3D471344=3D=3D Invalid write of size 8 =3D=3D471344=3D=3D at 0x40119E: main (test.cpp:15) =3D=3D471344=3D=3D Address 0x4dc3c80 is 0 bytes inside a block of size 64 = free'd =3D=3D471344=3D=3D at 0x483C59C: operator delete[](void*) (vg_replace_ma= lloc.c:649) =3D=3D471344=3D=3D by 0x40118F: main (test.cpp:14) =3D=3D471344=3D=3D Block was alloc'd at =3D=3D471344=3D=3D at 0x483B582: operator new[](unsigned long) (vg_replace_malloc.c:431) =3D=3D471344=3D=3D by 0x40114F: main (test.cpp:10) Alternatively I would accept a discussion of adding a systemtap trace point= to the tcache that allows you to use a tracer in a production system to look f= or such problems. This tracer would be a NOP unless activated. Have you evaluated adding an addition trace point? Using systemtap to find = this and print a userspace backtrace could be beneficial. Your suggested solution posted to libc-alpha is not acceptable given the performance implications. --=20 You are receiving this mail because: You are on the CC list for the bug.=