delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2026/03/02/13:30:40

DMARC-Filter: OpenDMARC Filter v1.4.2 delorie.com 622IUebc4187985
Authentication-Results: delorie.com; dmarc=pass (p=none dis=none) header.from=cygwin.com
Authentication-Results: delorie.com; spf=pass smtp.mailfrom=cygwin.com
DKIM-Filter: OpenDKIM Filter v2.11.0 delorie.com 622IUebc4187985
Authentication-Results: delorie.com;
dkim=pass (1024-bit key, unprotected) header.d=cygwin.com header.i=@cygwin.com header.a=rsa-sha256 header.s=default header.b=oXBMKCDq
X-Recipient: archive-cygwin AT delorie DOT com
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 712FD4BA23FF
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
s=default; t=1772476239;
bh=hUhdBJas56QqB7it+ukP2m5vpm7EjQlbRybMJ8Jmx9M=;
h=Date:To:In-Reply-To:References:Subject:List-Id:List-Unsubscribe:
List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:
From;
b=oXBMKCDq9iLHpo/Oct/+pQwsHO4Yyw1YQZfeiiDrDyfvp3oZL+TW77hUZngec77mQ
yamR6FIFnl0/CGpuHLCKE5v0eWza8AN8HBZWJtozjMSePkTXAOt0Mgex7J9VuFkhBX
XmVodjrW7ypjjtI3dunzbRFfTehkfC6/aRcJW2Cs=
X-Original-To: cygwin AT cygwin DOT com
Delivered-To: cygwin AT cygwin DOT com
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 52D344BA2E13
ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 52D344BA2E13
ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1772476219; cv=none;
b=cIEhBmzkNvRIVweqgaKmPT9OWQmizmwh1MTvX9veGxuWGS9ggeDVFJYNRWK0hI+2naJbvq5dzoabMckuRFhkShX1fCd1FTHpCQrWZBNRJvX8VOJjC4lJcvPhXrB8s3KkSmy2yQRB+uNkcylZmPGVrq4hPAF5L2EjuzZtSTf12Eg=
ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key;
t=1772476219; c=relaxed/simple;
bh=x5dMedrYexsEz2zfoyY2bIm/psl5ly3vIdebAQqlGVs=;
h=DKIM-Signature:Date:From:To:Message-ID:Subject:MIME-Version;
b=IRKMC+QZltum1X1MMsVUPDpdIh0nN94MAHmQM4A3SJLu2sOdxYdkgR8+df0/2+0xda1+5mWBSYT6pWlOo4a668cxQ9yjEkYkq/LyTsDKYle1wesFlgRgOeGzfCVNrILANo5/zpGOjuE+cKJSlC4AAiTFmI/qTKtrjYBi7GdYEsQ=
ARC-Authentication-Results: i=1; server2.sourceware.org
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 52D344BA2E13
Date: Mon, 2 Mar 2026 10:30:13 -0800 (PST)
To: Jakob Bohm <jb-cygwin AT wisemo DOT com>,
Jakob Bohm via Cygwin <cygwin AT cygwin DOT com>
Message-ID: <1628702321.468409.1772476213970@connect.xfinity.com>
In-Reply-To: <ec56b24e-e7a2-9b3b-74ac-5f6108b1435d@wisemo.com>
References: <547312365 DOT 1464244 DOT 1771958282029 AT connect DOT xfinity DOT com>
<aZ7PrbisVR1R4A7v AT dimstar DOT local DOT net>
<1670201592 DOT 1489273 DOT 1772043520008 AT connect DOT xfinity DOT com>
<e91d8b5b-2690-4271-aa74-e6226440e33d AT SystematicSW DOT ab DOT ca>
<1044918836 DOT 1507810 DOT 1772086967212 AT connect DOT xfinity DOT com>
<1579472684 DOT 1508349 DOT 1772092747339 AT connect DOT xfinity DOT com>
<aaABFf5iEowV1l7I AT xps13>
<1148572549 DOT 1808180 DOT 1772097444036 AT mail DOT yahoo DOT com>
<1901597260 DOT 1508573 DOT 1772100378936 AT connect DOT xfinity DOT com>
<0C965DD0-856E-41FF-B5A4-15E472292A32 AT unified-streaming DOT com>
<483908609 DOT 1508714 DOT 1772103775739 AT connect DOT xfinity DOT com>
<2346fd41-2500-0db6-5849-6788174b5a1d AT cs DOT umass DOT edu>
<1462848037 DOT 1521935 DOT 1772136952077 AT connect DOT xfinity DOT com>
<609655EE-8E9D-4522-A05C-F74C3FC89583 AT unified-streaming DOT com>
<957583332 DOT 1523179 DOT 1772138829815 AT connect DOT xfinity DOT com>
<6E812632-0E73-464A-AAB9-DC5BC5546B4C AT unified-streaming DOT com>
<ec56b24e-e7a2-9b3b-74ac-5f6108b1435d AT wisemo DOT com>
Subject: Re: Memmove causing program crashes, giving SIGTRAP in GDB(?)
MIME-Version: 1.0
X-Priority: 3
Importance: Normal
X-Mailer: Open-Xchange Mailer v7.10.6-Rev83
X-Originating-IP: ::ffff:50.47.202.14
X-Originating-Port: 19298
X-Originating-Client: open-xchange-appsuite
X-CMAE-Envelope: MS4xfCreGHvHvhoRcV0Gz6v9MHw6UscO/5haeV+tZIo7TlR5D7XCCtNAUDnS+0S7CMWzpiyUQhzXiUsQlqC56515XyMrLz6O844Zxs2eXtuyNvrmUqNfAWo0
wclQISJciMg/1am0YeeLOBiwz79iIV9gmOyPLFJzMgw9lMulK5cTcldNfo2vhSeQtE1cJRVX2+JTS8fbn2eLYTUC6XpISTBXuWTFs3DvT3BkR8mzxxOU4hWB
sq6agY/Adw03kMQh2L17Iw==
X-BeenThere: cygwin AT cygwin DOT com
X-Mailman-Version: 2.1.30
List-Id: General Cygwin discussions and problem reports <cygwin.cygwin.com>
List-Unsubscribe: <https://cygwin.com/mailman/options/cygwin>,
<mailto:cygwin-request AT cygwin DOT com?subject=unsubscribe>
List-Archive: <https://cygwin.com/pipermail/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-request AT cygwin DOT com?subject=help>
List-Subscribe: <https://cygwin.com/mailman/listinfo/cygwin>,
<mailto:cygwin-request AT cygwin DOT com?subject=subscribe>
From: KENNON J CONRAD via Cygwin <cygwin AT cygwin DOT com>
Reply-To: KENNON J CONRAD <kennonconrad AT comcast DOT net>
Errors-To: cygwin-bounces~archive-cygwin=delorie DOT com AT cygwin DOT com
Sender: "Cygwin" <cygwin-bounces~archive-cygwin=delorie DOT com AT cygwin DOT com>
X-MIME-Autoconverted: from base64 to 8bit by delorie.com id 622IUebc4187985 

Hi Jakob,

   The OS is Windows 8, which is getting pretty old these days.
   The CPU is i7-4790K, which is Haswell architecture.

   I don't know much about how the flags are supposed to be preserved other than what I
have read on the web recently.  What I do know is that:
1.  The program occasionally crashes when it uses memmove instead of code that should do exactly the
    same thing but avoids the memmove call.  When using memmove, there are approximately 3 million
    backward memmove calls on average per crash.  The released code (GLZA v0.1 - GLZA v0.11.8) that
    does not use memmove in this thread has been reliably doing the backward move for many years.
2.  When running under GDB, GDB occasionally (at approximately the same frequency as the crash) detects
    a SIGTRAP at the REP MOVSQ instruction in the memmove.
3.  The assembly code in memmove at the point of the SIGTRAP is:
    0x00007ff96ba812a8 <+136>: std
 => 0x00007ff96ba812a9 <+137>: rep movsq %ds:(%rsi),%es:(%rdi)
    0x00007ff96ba812ac <+140>: cld
4.  When the frame is set to the one that corresponds to the memmove function and registers are printed
    immediately following the SIGTRAP, GDB shows:
    eflags         0x246               [ PF ZF IF ]
    This appears to indicate DF is no longer set.
5.  The program itself does not use any low level thread functions or use OS calls.  The only thread
    functions that are used are pthread_create() and pthread_join().  None of the program threads that
    are running when this happens deallocate anything or protect any address ranges.
6.  There are no indications of address corruption and the data in the array that is being modified is
    consistent with the addresses that are shown in GDB at the point where the SIGTRAP occurs.

  What I am not sure about:
1.  Whether GDB accurately prints eflags.
2.  What causes GDB to issue the SIGTRAP while the REP MOVSQ is running.

It is not clear to me what you are calling "patent disinformation".  I am reporting what GDB shows and
what my experience with this crash has been.  If you could add some specific critiques, that would help
clarify what you are trying to say.

I would be happy to investigate further if I knew how to get additional information about the SIGTRAP.

Best Regards,

Kennon

> On 03/02/2026 5:32 AM PST Jakob Bohm via Cygwin <cygwin AT cygwin DOT com> wrote:
> 
>  
> 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 AT comcast DOT 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 AT unified-streaming DOT 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

-- 
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

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019