DMARC-Filter: OpenDMARC Filter v1.4.2 delorie.com 622DXDgl3945346
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 7F6B24BA23FB
Subject: Re: Memmove causing program crashes, giving SIGTRAP in GDB(?)
To: cygwin@cygwin.com
References: <547312365.1464244.1771958282029@connect.xfinity.com>
 <aZ7PrbisVR1R4A7v@dimstar.local.net>
 <1670201592.1489273.1772043520008@connect.xfinity.com>
 <e91d8b5b-2690-4271-aa74-e6226440e33d@SystematicSW.ab.ca>
 <1044918836.1507810.1772086967212@connect.xfinity.com>
 <1579472684.1508349.1772092747339@connect.xfinity.com>
 <aaABFf5iEowV1l7I@xps13> <1148572549.1808180.1772097444036@mail.yahoo.com>
 <1901597260.1508573.1772100378936@connect.xfinity.com>
 <0C965DD0-856E-41FF-B5A4-15E472292A32@unified-streaming.com>
 <483908609.1508714.1772103775739@connect.xfinity.com>
 <2346fd41-2500-0db6-5849-6788174b5a1d@cs.umass.edu>
 <1462848037.1521935.1772136952077@connect.xfinity.com>
 <609655EE-8E9D-4522-A05C-F74C3FC89583@unified-streaming.com>
 <957583332.1523179.1772138829815@connect.xfinity.com>
 <6E812632-0E73-464A-AAB9-DC5BC5546B4C@unified-streaming.com>
Organization: WiseMo A/S
Message-ID: <ec56b24e-e7a2-9b3b-74ac-5f6108b1435d@wisemo.com>
Date: Mon, 2 Mar 2026 14:32:51 +0100
MIME-Version: 1.0
In-Reply-To: <6E812632-0E73-464A-AAB9-DC5BC5546B4C@unified-streaming.com>
Content-Language: en-US
Precedence: list
From: Jakob Bohm via Cygwin <cygwin@cygwin.com>
Reply-To: Jakob Bohm <jb-cygwin@wisemo.com>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Errors-To: cygwin-bounces~archive-cygwin=delorie.com@cygwin.com
Sender: "Cygwin" <cygwin-bounces~archive-cygwin=delorie.com@cygwin.com>
Content-Transfer-Encoding: 8bit

Hi,

This is patent disinformation.  On any decent x86 operating system, the 
CPU scheduler that switches between threads preserves all registers and 
flags in a per thread context structure somewhere in the OS kernel.  The 
only thing another thread can do to interfere with a running REP MOVS is 
to deallocate / protect the address ranges accessed, and or use low 
level thread functions to change the saved registers of a non-running 
thread using OS calls such as (on Win32) SetThreadContext(), 
TerminateThread() and/or DebugActiveProcess() .

Also, a famous feature of x86 CPUs is that they will happily access 
unaligned memory using the basic integer instruction set, which includes 
REP MOVSQ, but not some of the wide MMX/SSE instructions that can be 
used for optimal memcpy/memmove implementations according to AMD and Intel.

Then there is of cause the ever-present spectre of a buggy CPU not doing 
what the code tells it to do.  Somewhere else in this thread, someone 
mentioned a specific such bug but stated the affected CPU models only in 
terms of code names.

On 26/02/2026 22:42, Dimitry Andric via Cygwin wrote:
> If such a crash occurs, can you do a "thread apply all bt" in gdb? This will show what all the other threads are doing. I'm betting some other thread is calling memcpy or some other function that is messing with the direction flag.
>
> -Dimitry
>
>> On 26 Feb 2026, at 21:47, KENNON J CONRAD<kennonconrad@comcast.net>  wrote:
>>
>> Yes, lots.  7 threads were running at the point of the crash  87% load on my i7-4790k.  I did a little research since the last post.  The memmove code where the crash occurs is:
>>
>>    0x00007ff96ba812a8 <+136>: std
>> => 0x00007ff96ba812a9 <+137>: rep movsq %ds:(%rsi),%es:(%rdi)
>>    0x00007ff96ba812ac <+140>: cld
>>
>> This sets the direction flag immediately before the rep movsq and clears the direction flag immediately after the rep movsq.  Yet when gdb breaks it shows the direction flag is not set:
>>
>> eflags         0x246               [ PF ZF IF ]
>>
>>   Would a forward move on overlapping data cause the SIGTRAP?  Could the code have moved to a different core?  Or could it have been interrupted by some other task that corrupts the flag?  As I mentioned earlier, the rep movsq is only failing once per several million times memmove is called so it seems likely to be something along those lines.
>>
>> -Kennon
>>
>>
>>> On 02/26/2026 12:20 PM PST Dimitry Andric<dimitry@unified-streaming.com>  wrote:
>>>
>>>
>>> Is there some concurrency going on? Maybe some other part of the program is flipping the direction flag?
>>>
>>> -Dimitry
>>>

Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded


-- 
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple