I have a 32 bit Debian Squeeze (so 2011 era, with gcc-4.4 - too early for asan - and libc 2.11, so two Debian releases earlier than Denis’s) chroot lying around. Unsurprisingly, his reproducer crashes for me too, configured with no options and make run with no arguments. gdb’s reporting line 119 rather than 118 in expand.c. valgrind annoyingly stops it crashing.
I had trouble compiling rule.c because johnny-come-lately mempcpy on this vintage setup seems to be provided as a macro and that doesn't play well with the STRING_SIZE_TUPLE macro, because, until the latter is expanded, mempcpy appears to only have two arguments, when it requires three. #undef mempcpy in rule.c got me over that. I know we depend on C99 now, seemingly without a storm of protest, but this is failing to compile on a setup a decade newer than that. For me, it’s the variable known in the make source as “environ”, which isn't what my gdb calls environ but what it calls ‘environ@@GLIBC_2.0' which has been corrupted, by the second call to recursively_expand_for_file, not, far as I sampled, the environment variables it points to. gdb alleged to let me set a hardware watch point on it but it didn't fire. It seems to have been corrupted to point into the middle of an environment variable. So what should be an array of character pointers is an array of characters. Interpreting those as character pointers promptly doesn't go so well. It’s already changed, for me, by the call to free_childbase. … And vfork is where that happens. If I’ve followed the thicket of #ifdef correctly and understood the vfork man page, then this is illegal when using vfork: https://github.com/mirror/make/blob/master/src/job.c#L2556 (I’d use the savannah git web thing but I don’t see line number links.) The corruption happening in another process would explain the hardware watch point not catching it. The “blame“ says that dodgy assignment is 28 years old but, as was recently topical again, we have stopped using posix_spawn instead of vfork with old libc versions and this code for copying the environment definitions of recursively expanded variables for $(shell) invocations is even newer. Perhaps Make didn’t otherwise use the environ variable that it’s illegally corrupted for the last three decades. ________________________________ From: Bug-make <bug-make-bounces+martin.dorey=hds....@gnu.org> on behalf of Paul Smith <psm...@gnu.org> Sent: Saturday, September 24, 2022 14:17 To: Denis Excoffier <bug-...@denis-excoffier.org> Cc: bug-make@gnu.org <bug-make@gnu.org> Subject: Re: 4.3.90 release candidate segfaults on linux and solaris ***** EXTERNAL EMAIL ***** On Sat, 2022-09-24 at 13:06 -0400, Paul Smith wrote: > > The crashes in solaris and linux are so similar, and go away also > > so similarly, that i would primarily think about size of types. > > Under cygwin and MacOS all sizes (pointers, long int, size_t, > > SIZE_MAX, time_t) are 8, while under (this) solaris and (this) > > linux all sizes are 4. Only size of int is 4 on all. > > Aha! You're using a 32bit Linux. That is indeed helpful > information, thanks. I will check it. I installed a 32bit docker container and tried with that but still no failure. I will keep poking at it; maybe I can find a much older container.
