On Feb 14 10:52, Corinna Vinschen via Cygwin wrote: > On Feb 13 15:48, Kevin Ushey via Cygwin wrote: > > Here's a bit more information from a debug build of cygwin; here I'm > > just trying to launch cygpath.exe: > > > > (gdb) f 1 > > #1 0x00007ffa0123ba1f in find_fast_cwd_pointer () at > > ../../../../winsup/cygwin/path.cc:4526 > > 4526 const uint8_t *lock = (const uint8_t *) > > > > (gdb) bt > > #0 memmem (haystack=<optimized out>, hs_len=<optimized out>, > > needle=0x7ffa0142e531 <_C_collate_locale+59857>, ne_len=4) at > > ../../../newlib/libc/string/memmem.c:161 > > #1 0x00007ffa0123ba1f in find_fast_cwd_pointer () at > > ../../../../winsup/cygwin/path.cc:4526 > > [...] > > Ok, so we know now which memmem call fails, so the next question is, > why? The haystack address is unfortunately still optimized out in > memmem, so it looks like the newlib subdir is still optimized. > But it's pretty certainly a wrong haystack address. This address has > been fetched from > > const uint8_t *rcall = (const uint8_t *) memchr (get_dir, 0xe8, 80); > ... > const uint8_t *use_cwd = rcall + 5 + peek32 (rcall + 1); > > Chances are high, that the call instruction found by rcall is bogus.
Can you run this in GDB? I'd love to see the assembler code starting at address `get_dir'... Corinna -- 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
