bugmake - Bugs: bug #64129, Using $(filter ...) on a variable...

 
 

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

Submitter:  None
Submitted:  Sun 30 Apr 2023 07:46:59 PM UTC
   
 
Severity:  3 - Normal Item Group:  Bug
Status:  Duplicate Privacy:  Public
Assigned to:  None Open/Closed:  Closed
Component Version:  4.3 Operating System:  POSIX-Based
Fixed Release:  None Triage Status:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Mon 01 May 2023 04:09:33 AM UTC, comment #4: 

Duplicate of bug #59093 thanks for looking that up Martin.

Paul D. Smith <psmith>
Group administrator
Mon 01 May 2023 12:04:12 AM UTC, comment #3: 

Thanks for your help! I'll look into upgrading.

Colin Parker <cvparker>
Sun 30 Apr 2023 11:22:58 PM UTC, comment #2: 

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.

Martin Dorey <mdorey>
Sun 30 Apr 2023 07:53:20 PM UTC, comment #1: 

This was my submission if anyone wants to contact me about it, sorry for submitting anonymously. I thought the site would ask my information at a later step.

Colin Parker <cvparker>
Sun 30 Apr 2023 07:46:59 PM UTC, original submission:  

If I try to use the filter function on a variable that consists of a large number of words (174k or so), make crashes with segmentation fault. This appears to be roughly independent of the size of the words themselves.

System is Linux Mint Debian Edition, kernel is Debian 5.10.162-1 (2023-01-21) x86_64 GNU/Linux, bash version 5.1.4(1)

The attached Makefile will generate a variable with sequential numbers up to 274369 (crudely encoded in the first 6 lines) and attempt to filter from it, which seg faults. If the value (on my system) is reduced to 174369 make fails roughly half of the time. That's an approximate limiting value based on quick testing and if made higher or lower by 1000 it will respectively succeed or fail every time. The numbers can be padded to 10 digits or left at 6 digits and the result is the same. If the "filter" line is commented out then larger numbers of words can be used, so the problem is likely in "filter" and not in "words" or in the variable handling within make.

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #54692:  Makefile added by None (1KiB - application/octet-stream - just run "make" but see description for how to interpret)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by psmith (Posted a comment)
  • -email is unavailable- added by mdorey (Posted a comment)
  • -email is unavailable- added by cvparker (Posted a comment)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2023-05-01 psmith StatusNone Duplicate
        Open/ClosedOpen Closed
    2023-04-30 None Attached File- Added Makefile, #54692

    Back to the top

    Powered by Savane 3.13-4b48.
    Corresponding source code