Follow-up Comment #2, bug #64129 (project make): Problem reproduced in 4.3, as claimed in OP. Problem not reproduced in 3.81, 4.1, 4.2.1, 4.3.90, 4.3.91, 4.3.92, 4.4.0.90, 4.4.0.91, 4.4.90 (today's code). Stack trace:
In 4.3: (gdb) bt #0 0x000055555556828d in func_filter_filterout (o=0x5555555beee0 "", argv=<optimized out>, funcname=<optimized out>) at ../../src/function.c:999 #1 0x000055555556921a in handle_function (op=op@entry=0x7fffffffa260, stringp=stringp@entry=0x7fffffffa258) at ../../src/function.c:2544 #2 0x0000555555562dcf in variable_expand_string (line=<optimized out>, line@entry=0x0, string=string@entry=0x5555555c3fed "$(filter 000000$(EXTRA_ZERO),$(NUMBERS))", length=length@entry=18446744073709551615) at ../../src/expand.c:258 #3 0x00005555555638c1 in variable_expand (line=0x5555555c3fed "$(filter 000000$(EXTRA_ZERO),$(NUMBERS))") at ../../src/expand.c:417 #4 variable_expand_for_file (file=0xc8, line=0x5555555c3fed "$(filter 000000$(EXTRA_ZERO),$(NUMBERS))") at ../../src/expand.c:464 #5 allocated_variable_expand_for_file (line=line@entry=0x5555555c3fed "$(filter 000000$(EXTRA_ZERO),$(NUMBERS))", file=file@entry=0x0) at ../../src/expand.c:566 #6 0x000055555557df8f in do_variable_definition (flocp=0x7fffffffa5e8, varname=0x5555555be690 "FOUND_NUM", value=0x5555555c3fed "$(filter 000000$(EXTRA_ZERO),$(NUMBERS))", origin=o_file, flavor=<optimized out>, target_var=0) at ../../src/variable.c:1187 #7 0x000055555557e89f in try_variable_definition (flocp=flocp@entry=0x7fffffffa5e8, line=line@entry=0x5555555c3fe0 "FOUND_NUM := $(filter 000000$(EXTRA_ZERO),$(NUMBERS))", origin=origin@entry=o_file, target_var=target_var@entry=0) at ../../src/variable.c:1633 #8 0x00005555555761ab in eval (ebuf=ebuf@entry=0x7fffffffa5c0, set_default=<optimized out>) at ../../src/read.c:752 #9 0x00005555555779be in eval_makefile (filename=<optimized out>, flags=flags@entry=0) at ../../src/read.c:438 #10 0x0000555555577df9 in read_all_makefiles (makefiles=<optimized out>) at ../../src/read.c:260 #11 0x000055555555e7c6 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at ../../src/main.c:1945 (gdb) valgrind reports stack overflow: martind@platinum:~/tmp/make-64129$ valgrind /usr/bin/make ==1575663== Memcheck, a memory error detector ==1575663== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==1575663== Using Valgrind-3.16.1 and LibVEX; rerun with -h for copyright info ==1575663== Command: /usr/bin/make ==1575663== ==1575663== Stack overflow in thread #1: can't grow stack to 0x1ffe801000 ==1575663== ==1575663== Process terminating with default action of signal 11 (SIGSEGV) ==1575663== Access not within mapped region at address 0x1FFE801FF8 ==1575663== Stack overflow in thread #1: can't grow stack to 0x1ffe801000 ==1575663== at 0x11C27F: func_filter_filterout (function.c:1013) ==1575663== If you believe this happened as a result of a stack ==1575663== overflow in your program's main thread (unlikely but ==1575663== possible), you can try to increase the size of the ==1575663== main thread stack using the --main-stacksize= flag. ==1575663== The main thread stack size used in this run was 8388608. ==1575663== Stack overflow in thread #1: can't grow stack to 0x1ffe801000 ==1575663== ==1575663== Process terminating with default action of signal 11 (SIGSEGV) ==1575663== Access not within mapped region at address 0x1FFE801FE8 ==1575663== Stack overflow in thread #1: can't grow stack to 0x1ffe801000 ==1575663== at 0x482E110: _vgnU_freeres (vg_preloaded.c:57) ==1575663== If you believe this happened as a result of a stack ==1575663== overflow in your program's main thread (unlikely but ==1575663== possible), you can try to increase the size of the ==1575663== main thread stack using the --main-stacksize= flag. ==1575663== The main thread stack size used in this run was 8388608. ==1575663== ==1575663== HEAP SUMMARY: ==1575663== in use at exit: 6,854,714 bytes in 1,219 blocks ==1575663== total heap usage: 1,159,139 allocs, 1,157,920 frees, 143,765,954 bytes allocated ==1575663== ==1575663== LEAK SUMMARY: ==1575663== definitely lost: 0 bytes in 0 blocks ==1575663== indirectly lost: 0 bytes in 0 blocks ==1575663== possibly lost: 0 bytes in 0 blocks ==1575663== still reachable: 6,854,714 bytes in 1,219 blocks ==1575663== suppressed: 0 bytes in 0 blocks ==1575663== Rerun with --leak-check=full to see details of leaked memory ==1575663== ==1575663== For lists of detected and suppressed errors, rerun with: -s ==1575663== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) Segmentation fault martind@platinum:~/tmp/make-64129$ Yeah, this is a dupe of the already-fixed: https://savannah.gnu.org/bugs/?59093 Segmentation fault regression in make 4.3 vs. 4.2.1 I'm confident because reverting the fix e49e11e069fe7f214263be1782242b9b50f71eaa reintroduces it. _______________________________________________________ Reply to this item at: <https://savannah.gnu.org/bugs/?64129> _______________________________________________ Message sent via Savannah https://savannah.gnu.org/