[bug #64129] Using $(filter ...) on a variable with a large number of words causes seg fault

[Martin Dorey]

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/