Memmove causing program crashes, giving SIGTRAP in GDB(?)

[KENNON J CONRAD]

Hi Glenn,

   Thanks for the tips.  I think I mentioned that I am a first time user of gdb, so tips like this are very helpful.  I was having problems debugging at first, getting nothing useful, and did a web search and found a suggestion to compile with -O0 and -g.  Once I did that change in the Makefile I got the first result I posted on the first try.  Then for today's run I switched the -g to -ggdb to see if it made any difference and didn't notice anything.

  This memmove call is for clearing a spot in the ranked list to insert a new entry in the list by moving everything after it 2 bytes to the right.  So the intent of the code is to move each byte pair (uint16) to the right by 2 bytes starting at the end of the list (deleting the last entry if the list is full, which has not been in both crash cases).

Best Regards,

Kennon


> On 02/25/2026 10:47 PM PST Glenn Strauss <gs-cygwin.com@gluelogic.com> wrote:
> 
>  
> On Wed, Feb 25, 2026 at 10:22:47PM -0800, KENNON J CONRAD via Cygwin wrote:
> > Hi Brian,
> > 
> >    I installed the version of the cygwin-debuginfo that is on my test computer to the build machine (version 3.6.6-1).  I put the memmove back in the code in place of the bloated code that has been running the past 4 days without any problem (and the past ~10 years before changing to memset) and got another SIGTRAP in gbd on that memset within 2 hours.  The backtrace looks very similar:
> 
> When debugging issues with low-level library calls such as memmove,
> I highly suggest testing using reduced compiler optimization settings.
> 
> If you can, pull the function in question into a separate .c or .cxx
> file, and compile that translation unit with -Os -ggdb.  If you can
> reproduce the issue, compile that translation unit with -O0 -ggdb and
> try again.
> 
> Question: are you replacing old code with memmove() from address x+y to
> address x, i.e. shifting left?  Or are replacing existing code with
> memmove() and shifting right onto overlapping ranges?  In both cases for
> memmove(), the resulting assembly code should detect if the ranges
> overlap and should not overwrite existing data before it gets moved.
> 
> Cheers, Glenn