From nobody Fri Jan 14 12:44:36 2022 X-Original-To: freebsd-current@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 9830619418B9 for ; Fri, 14 Jan 2022 12:44:49 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic306-19.consmr.mail.gq1.yahoo.com (sonic306-19.consmr.mail.gq1.yahoo.com [98.137.68.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jb1GS1xygz4WcD for ; Fri, 14 Jan 2022 12:44:48 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1642164280; bh=C2R3zBH7NQ+2EGTt+JIUizDrJxIZCx9sH0z65TVHTDE=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=nrWNfZE2SNqaucfhjNxuwcBQVQeiaMBhkcB09eUJgg82hIZSQ7n2aR+eBUfJS6lu52tnZJcw7xQ1vK6gVFRHgst2tfvpHcs3Rhn7q1lKITeEHqKVUjLrakfdd+/GCaFYfIJM549N2N2qT1HeFRs8aC5F8qo322SbcgB5gimIzDl9O2zji42eB43zcAd8lMOUPBRMJu89bVB8h8HZOJfHuGSOdtS8kfkNv2rYxFJZM4PPdYPztmRWbvwOcQOPjQZeF9QGxsRzjxyseirVbotnaggu4KC0g9y6ZvD7VRkvbM44oUD2FCVv4zm//66mgmFiolZO8TYNFcWrliMXrUpOVQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1642164280; bh=DI1AydocNfa4ksL8SGLujm21c0VdSsHPgnjcE95Pn1d=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=B6pmPUThQ5rtF5Fs4DzyJqeu7tC2QnhDHfU8XdqmNf2Of4CXdW05qhPU6lN1Gz0sJHYhMqh9V99Idv9lh9iz8GGaxW4RQJeeprgcO/XbOJ+2yXBtZf3Eavqz1dixjxEeEwUcX0r5ZBhG/OGIEKRZIve1L8X91FHthnpNA9D1mVEC9S1JfitcwVT3eMVmnx6hg13apCqREiaTD5lIw7NS/IGKhHfkLDR8K5kGUTAGaAKNc3OkOx+RS27Go6Juiqz4ovIlPLiSTi3ZhTmoyxmWAvoApxHLRngwp1x3hRWRnMWIpb15uflXAeP7iD1FDi8Rbni/c/lsobmANpZtiMPpTQ== X-YMail-OSG: vyZcL8kVM1lO_zDwsp3IJWq0GuZpVUCC7Wxjx0pxxksneqMZjxYbErieGKk4ENR yAXBpTZJ1yMLbZuKpS_diYlVTC5T3zKUtEaRw0wjKGgIqIqXS9KgmaeLpH_J5_0rTvvqhQjz0DwD Ctt8mnSTNbMt_3kKR4.1xQgN_gIsdiPRVYoG2H.6xyxsU.Yf717XmOHYeRi3SBW1xSolDMvVu5cS pg5BO4kob5DnND3SlaiCenjWDZcKlqYXvg87hybNYCicqQ1dNuT8V2JlipUjBhMpR.2XKta4ZcP9 Nk54LBHuzb.ghAjLPU.SVrjlSCBB.txN7inOQJJBkFK6QandYOSyZEGoWB8RYkqM6rYHD.ik5iNy V7_VMitcwB3AQniRbSxXM_SDRYtpnaP_fHL1OWYYEq9eU5NR9xXO0VqO1kA5Rf0T_NDqyY0qTEFn 2AI0d0MjxXP3Dzh6W07FZihUfkClaHgpOfiIMyDj8mOP7fgjR_ZarQh3Yhse__git345_t4f7KjG uecud0dHPI.EmOQf8c3MODPfRdB5bBHsePx49O8iQLSy49U8ACOeETjzclR__AoIfzi2eDCWCnEW vRvWnuzHQVeRYaAMczF9nptd43aXVibQihhQxMAMLArzcLO2V6ORs6CntvtyvoykTcVS6wTAyQKy rnVbmWSOOUotRq7e3wNvoQElBjboqFG.LIPDOtuTdEuMRlnXEaCYjg940NH.jTBypTB0OpekOUSC wYjoaahszxvIVZo4Hb0yIaALS8VYRbfTtAyuwgN2bMb6kF3LKeGnUOglUXSABcOxJIvPCS4c.lMQ s.CFLP14Zg5jcpGm70j1xsVLEHP_hkLj6zTrxUbqreYQsZlaNXexcdW16FnGt_clM3sxYrf9JurT 2jLI4UKxNNllFRD1OkNn8w7Violxc0Le_Ckdg7pQMw459rgXbhymdKZLJVGI_wTYBSqqDMTDdKOa xm8w7Fz5a71_AmC_ZjZw1WEjmYSuY8CQsHAHEarIG.9Pgq0p40wUR9U0mKwc5yGOGCfwHCNsTZC6 U0Vl9W3chO5Pw9gfHY6Z8NSIceH3pbhOvmf.K9XHDikh45K5lAJvEqJ.BJl1Hc7TzA2bM_ntnVSq 0pVUB8i.N35.WH8t9IsCMn5MkxvbJOleybN2O.LUQocXyOcHfgdrMz8PluFlAh9Ch51lXMzwJj7A 9yxGhF3iQDvTrQB3qYXuI4F3ZByblR7WtkKSut4onfWUkiEgBMRAdvCeK_slAo0EKwOKzXWocAxh 2vRkVCAh_gmrugHSgB8DW646WBbN2gVs0C.RcM1EB7nnul0ng9zc9SiDIpz71n.cC0zpgfGYXBGO 2qtauTmMl2jvM2mnkSR_evGnCkycpYQRy0ZkSya3F81ing3WXhI6xDm56FQ3h6A5yR9yhrej9nQl CozierzFe__zLrLi7tu0hFWOXDbD1K5Yf0hoz1VZc0Z.ue3RKBEkgbVgEfEhL8Ir96_o_SZHiZTH 3UVxQlcVAflNMggEa2Vbyvf416k9GRvAGZzFkz4aW2ha6CnJSeZRtKLbX.0RpUWmlL1NdFHXklaM rBnBV5_g7rPnKRXSosyG5EXOrulwEXWAh2wlOz0mgmgm5lgnJm7S6QeDDyMlosfWyK0sM9pJWAf4 TevjX.pUZcHh058U2EZ8MsafpoGSUjD.D3Q02wRpurqW3J96d3OcuI5RMmiCVSIYdnya4ng_KHuS kEhkhljHijppw5bny0TjeP6CXSMvNKnLcV9pT6HzWJYgwnVE10oNZtbsO5wReLfnFgopY4gqmBvP IKDrVGRDx6v.6v20BO6Q5eWjjz7bJJeIsYjUDTDJqqJvj6alnhOq5zpTjwfwIEQGhFgYpPBH9NEy UV5rXYw5th.s5W.5.BRC5aSf2rmUmGNxRf7tZSlBZUkLm4yIK2aHWjEQDvH5Dxd6K.7c3dcjXUDL dEVTJ3_aR5ZYRDaslyQlWQxHiOXNdtWCtDx431IJnt_kTZamJ4N0C5vX.5XvNYoD7VWa9eRHhy_0 zzgIfZQTBKxreVTUPF2I.M1BEHknr1LTQC_QlY11t4AwBlyuYYlWeQ8bi.vG04P8shBcqPF4WwPq Nfz9zQkBlAfrgk71Ut5pj2PssoehveKJzr8ubgzoX1BQWf2C7ettuT72PpAJbU302SVh5CohanC5 C.LNH05bap2tSNsEVLnESO16P3TJnwKOKhQEwAbLL2Jwl6KPC.db2.vNKOPFKl6SjGFls6pIRhnC pxPiUxelxZ4kwC.25DKoGXETgLMBcC8FlnH4oen8HGGXsyDTirD5AREtC7H1aT4JjzKhldCyRXa8 - X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Fri, 14 Jan 2022 12:44:40 +0000 Received: by kubenode521.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 9121485339796eccfdd38e3492301fd9; Fri, 14 Jan 2022 12:44:36 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: An explanation of some "Container overflow" ASAN reports Message-Id: <22B11810-DB3F-4E81-AB40-ED207CD83EEE@yahoo.com> Date: Fri, 14 Jan 2022 04:44:36 -0800 To: freebsd-current X-Mailer: Apple Mail (2.3654.120.0.1.13) References: <22B11810-DB3F-4E81-AB40-ED207CD83EEE.ref@yahoo.com> X-Rspamd-Queue-Id: 4Jb1GS1xygz4WcD X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=nrWNfZE2; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.82 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.82:from]; MLMMJ_DEST(0.00)[freebsd-current]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.82:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Looks like libc++ does the following sort of thing (from lldb list): . . . 1635=09 1636 template 1637 template 1638 void 1639 #ifndef _LIBCPP_CXX03_LANG (lldb)=20 1640 vector<_Tp, _Allocator>::__push_back_slow_path(_Up&& __x) 1641 #else 1642 vector<_Tp, _Allocator>::__push_back_slow_path(_Up& __x) 1643 #endif 1644 { 1645 allocator_type& __a =3D this->__alloc(); 1646 __split_buffer = __v(__recommend(size() + 1), size(), __a); 1647 // __v.push_back(_VSTD::forward<_Up>(__x)); 1648 __alloc_traits::construct(__a, = _VSTD::__to_address(__v.__end_), _VSTD::forward<_Up>(__x)); 1649 __v.__end_++; (lldb)=20 1650 __swap_out_circular_buffer(__v); 1651 } . . . (the bt points to 1650) . . . 1648 constructs into __v at __v.__end_ and 1649 then corrects __v.__end_ to cause the constructed object to no longer be an example of "Container overflow" but now in the Container. (At least that is my interpretation.) The compiler's code generation may move the detailed place where __v.__end_++ happens relative to some other of the activity but the compiler has been told an order relative to the construction that would lead to writing memory in the capacity of the container __v but outside the size of the __v container at the time. For reference: 970 template 971 void 972 vector<_Tp, = _Allocator>::__swap_out_circular_buffer(__split_buffer& __v) 973 { 974 =09 975 __annotate_delete(); 976 = _VSTD::__construct_backward_with_exception_guarantees(this->__alloc(), = this->__begin_, this->__end_, __v.__begin_); 977 _VSTD::swap(this->__begin_, __v.__begin_); 978 _VSTD::swap(this->__end_, __v.__end_); 979 _VSTD::swap(this->__end_cap(), __v.__end_cap()); (lldb)=20 980 __v.__first_ =3D __v.__begin_; 981 __annotate_new(size()); 982 __invalidate_all_iterators(); 983 } . . . (the bt for this points to 976) . . . This suggests to me that using some equivalent of: env ASAN_OPTIONS=3Ddetect_container_overflow=3D0 my be required fairly generally when libc++ can be involved. Other notes . . . I used ld -v as an example for the above via: env ASAN_OPTIONS=3Ddetect_container_overflow=3D0 lldb ld and used: (lldb) env ASAN_OPTIONS=3D (lldb) run -v in order to have ld itself not have detect_container_overflow disabled. lldb suffers the libc++ Container overflow problems via its libc++ use and fails to operate without the: ASAN_OPTIONS=3Ddetect_container_overflow=3D0 =3D=3D=3D Mark Millard marklmi at yahoo.com