From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from kate-mail.whsl206.com ([49.50.249.113]) by ewsd; Mon Mar 9 05:40:43 EDT 2020 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=qs.co.nz; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=cZZGXroqHzfcdcIiI2bYxkXW8h8gcx3gVCww94MEPg0=; b=CobxUylRdxpaxcdgwBRI7MXG9v bsIPNGc/uzDPQqwg1OCH+tLEns0z3grEg62yHm0qj3CAtKjkcvfMgQiHcRD1uP78ZrhJOQKXGpO9y zJ9494tJ5fSauvzKmAiV7Oz7A3sHSRlCY6yuop46WvYcuKEpM/9t2lUcMmOIRAXkeRBL3QRToteeq Zkt9mKJnxkzy14GIpnQsfcCEpc/KKPFztYfhmyR/9S2SDvsAN9TFLVSvqh0OvKnh6whL6in0CJw5D Z2uApRL8mvain6vt5H498TaEW4KF8oDpbf+0GZkKD56yivc7GGa85Bf7xuKJflYIj1YRzDS3nB3FZ +Xj6BYAg==; Received: from [118.149.151.44] (port=2842 helo=[192.168.43.110]) by kate.whsl206.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1jBEt3-002fRy-QB for 9front@9front.org; Mon, 09 Mar 2020 22:39:50 +1300 Subject: Re: [9front] APE stddef.h ptrdiff_t should it be 8? [Tcl memory problem] To: 9front@9front.org References: From: Trevor Higgins Message-ID: <9fc99a18-95f6-a43c-7933-808c3e9d92bc@qs.co.nz> Date: Mon, 9 Mar 2020 22:39:46 +1300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - kate.whsl206.com X-AntiAbuse: Original Domain - 9front.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - qs.co.nz X-Get-Message-Sender-Via: kate.whsl206.com: authenticated_id: phil@qs.co.nz X-Authenticated-Sender: kate.whsl206.com: phil@qs.co.nz X-Source: X-Source-Args: X-Source-Dir: List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: shared SQL descriptor high-performance pipelining realtime controller On 03/09/2020 05:06 PM, ori@eigenstate.org wrote: > > I'd really like to know what went wrong with tcl, and how > to reproduce it. > Ok, but you need to understand the tcl code to follow along. Compile with amd64 and run. It generates a TclPanic due to a pointer passed to the StackFree routine not matching the value expected. This is caused by the macro OFFSET (inline func actually) in TclExecute.c. In tcl8.6 the macro has been renamed wordskip as this is a more appropriate name. At first glance it looks like the macro computes the number of bytes needed to align the address to 16 bytes. But it does not. It should return either 1 or 2 but it does so only when the address passed in is XXXX0 or XXXX8. When an address of XXXC is used, the macro returns 0. Any other low order address bit combinations will also be barf. The zero value causes the Macro MEMSTART to return the wrong address to the application. The offset is needed for space to store a marker that is used by the StackFree routine. The application writes all over the marker and thus the panic. The second problem is two fold. In TclExcuteByteCodeObj (or therabouts), the code keeps track of how much of the stack memory is in use with two values that are ptrdiff_t. Except they are pointers to ptrdiff_t. When the said routine returns the memory back to the stack allocator it uses ptr+1 (for some unknown reason). Because ptrdiff* is int* it adds four to the address. It needs to add 8 for the code to work properly. Why the +1 I do not know, it looks like a "off by 1 hack" but in all other cases, the Value returned to StackFree is the same value given by StackAlloc. The second problem is that memory accesses occur outside the allocated memory. Without passing properly aligned memory addresses to this routine it cannot be investigated further and may go away once the above is corrected. Why tcl needs the memory to be 128bit aligned I have not looked into. But I suspect it is the way the byte code engine converts word to byte addresses. In any case, in running some code with some patches in to address the above , I still get memory corruptions and 'suicide traps' due to the code accessing memory that is not within the application. IE the high word of the pointer has become corrupted. The machine I am using is second hand and I have not used it much for anything else, other than installing Linux on one partition , so it could be memory problems with this machine. I verified most of the above with QEMU but in qemu with the OFFSET fix applied there are no other random memory panics. I suspect it just depends on the value of the pointers passed from malloc and that under QEMU I am not seeing the ones that cause the problem. -- We need another plan