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

[Paul D. Smith]

Update of bug #64129 (project make):

  Status:None => Duplicate  
 Open/Closed:Open => Closed 

___

Follow-up Comment #4:

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


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #64016] Simplify update_goal_chain.

[Dmitry Goncharov]

Follow-up Comment #5, bug #64016 (project make):

This made me think, why don't we also test the opposite situation?
That's that in the sequential mode make does not advance to the next target,
until the current target is finished.


diff --git a/tests/scripts/features/double_colon
b/tests/scripts/features/double_colon
index 4631c355..5aad531f 100644
--- a/tests/scripts/features/double_colon
+++ b/tests/scripts/features/double_colon
@@ -234,6 +234,23 @@ bye.x::; @#HELPER# sleep 1 file $@
 !,
   '-j2 hello.x bye.x', "sleep 1\nfile bye.x\nhello.x");
 
+unlink('bye.x');
+
+# This test is the opposite of the prior one.
+# Test that in the sequential mode (-j1) update_goal_chain does not move to
the
+# next target until the current target is finished.
+# There is an intended deadlock here.
+# hello.x:: recipe is started and its recipe blocks until file bye.x
appears.
+# bye.x cannot appear until bye.x:: recipe runs. bye.x:: recipe cannot run
+# until hello.x:: recipe is finished.
+# The test apparatus aborts the test in 10 seconds.
+
+run_make_test(q!
+hello.x::; @#HELPER# -q wait bye.x out $@
+bye.x::; @#HELPER# sleep 1 file $@
+!,
+  'hello.x bye.x', "wait bye.x: timeout after 10 seconds\n#MAKE#:
*** [#MAKEFILE#:2: hello.x] Error 2\n", 512);
+unlink('bye.x');
 
 # This tells the test driver that the perl test script executed properly.
 1;




___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #64016] Simplify update_goal_chain.

[Dmitry Goncharov]

Follow-up Comment #4, bug #64016 (project make):

[comment #2 comment #2:]
> I don't understand the test that was added though.  How does this test show
that both rules are run at the same time?  It seems like it would behave the
same even if they were not.

Indeed. My test was lacking necessary synchronization.

> Don't you mean something like this:

> run_make_test(q!
> hello.x::; @#HELPER# -q wait bye.x out $@
> bye.x::; @#HELPER# sleep 1 file $@
> !,
>   '-j2 hello.x bye.x', "sleep 1\nfile bye.x\nhello.x");


> ?

This is a good test.
Thanks for review and for catching this, Paul.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Colin Parker]

Follow-up Comment #3, bug #64129 (project make):

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


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[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  0x5556828d in func_filter_filterout (o=0x555beee0 "",
argv=, funcname=) at ../../src/function.c:999
#1  0x5556921a in handle_function (op=op@entry=0x7fffa260,
stringp=stringp@entry=0x7fffa258) at ../../src/function.c:2544
#2  0x55562dcf in variable_expand_string (line=,
line@entry=0x0, string=string@entry=0x555c3fed "$(filter
00$(EXTRA_ZERO),$(NUMBERS))", length=length@entry=18446744073709551615) at
../../src/expand.c:258
#3  0x555638c1 in variable_expand (line=0x555c3fed "$(filter
00$(EXTRA_ZERO),$(NUMBERS))") at ../../src/expand.c:417
#4  variable_expand_for_file (file=0xc8, line=0x555c3fed "$(filter
00$(EXTRA_ZERO),$(NUMBERS))") at ../../src/expand.c:464
#5  allocated_variable_expand_for_file (line=line@entry=0x555c3fed
"$(filter 00$(EXTRA_ZERO),$(NUMBERS))", file=file@entry=0x0) at
../../src/expand.c:566
#6  0x5557df8f in do_variable_definition (flocp=0x7fffa5e8,
varname=0x555be690 "FOUND_NUM", value=0x555c3fed "$(filter
00$(EXTRA_ZERO),$(NUMBERS))", origin=o_file, flavor=,
target_var=0) at ../../src/variable.c:1187
#7  0x5557e89f in try_variable_definition
(flocp=flocp@entry=0x7fffa5e8, line=line@entry=0x555c3fe0 "FOUND_NUM
:= $(filter 00$(EXTRA_ZERO),$(NUMBERS))", origin=origin@entry=o_file,
target_var=target_var@entry=0) at ../../src/variable.c:1633
#8  0x555761ab in eval (ebuf=ebuf@entry=0x7fffa5c0,
set_default=) at ../../src/read.c:752
#9  0x555779be in eval_makefile (filename=,
flags=flags@entry=0) at ../../src/read.c:438
#10 0x55577df9 in read_all_makefiles (makefiles=) at
../../src/read.c:260
#11 0xe7c6 in main (argc=, argv=,
envp=) 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:

  

___
Message sent via Savannah

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

[Colin Parker]

Follow-up Comment #1, bug #64129 (project make):

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.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[anonymous]

URL:
  

 Summary: Using $(filter ...) on a variable with a large
number of words causes seg fault
   Group: make
   Submitter: None
   Submitted: Sun 30 Apr 2023 07:46:59 PM UTC
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: 4.3
Operating System: POSIX-Based
   Fixed Release: None
   Triage Status: None


___

Follow-up Comments:


---
Date: Sun 30 Apr 2023 07:46:59 PM UTC By: Anonymous
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.






___
File Attachments:


---
Date: Sun 30 Apr 2023 07:46:59 PM UTC  Name: Makefile  Size: 1KiB   By: None
just run make but see description for how to interpret


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

Re: [PATCH] Use UTF-8 active code page for Windows host.

[Eli Zaretskii]

> From: Paul Smith 
> Cc: bug-make@gnu.org
> Date: Sun, 30 Apr 2023 09:55:55 -0400
> 
> On Tue, 2023-04-11 at 15:29 +0300, Eli Zaretskii wrote:
> > I agree with the list.  As for Basic.mk, we can forget about it from
> > my POV.  Paul should make the call, but from my POV that file was
> > unmaintained and therefore unsupported.
> 
> Why do we think it's unmaintained / unsupported?

Because I never use it when building the MinGW port of Make.

Re: [PATCH] Use UTF-8 active code page for Windows host.

[Paul Smith]

On Tue, 2023-04-11 at 15:29 +0300, Eli Zaretskii wrote:
> I agree with the list.  As for Basic.mk, we can forget about it from
> my POV.  Paul should make the call, but from my POV that file was
> unmaintained and therefore unsupported.

Why do we think it's unmaintained / unsupported?  It worked the last
time I tried it.  The advantage it has over run build_w32.bat is that,
since it uses make, it will only rebuild things that have changed and
not everything, which can be helpful if you're doing iterative
development.

[bug #63868] Document MAKEFLAGS pitfalls.

[Paul D. Smith]

Update of bug #63868 (project make):

 Summary: Document MAKEFLASG pitfalls. => Document MAKEFLAGS
pitfalls.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #64016] Simplify update_goal_chain.

[Paul D. Smith]

Update of bug #64016 (project make):

  Status:None => Fixed  
 Open/Closed:Open => Closed 
   Fixed Release:None => SCM
   Triage Status:None => Small Effort   

___

Follow-up Comment #3:

I pushed this with my different test.  Hope it's OK.  Thanks Dmitry.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #64107] -R and -r settings in MAKEFLAGS are delayed until build time

[Paul D. Smith]

Update of bug #64107 (project make):

  Status:None => Fixed  
 Open/Closed:Open => Closed 
   Fixed Release:None => SCM
   Triage Status:None => Medium Effort  

___

Follow-up Comment #3:

Pushed, thanks Dmitry.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #64115] make warns about undefined variable GNUMAKEFLAGS

[Paul D. Smith]

Update of bug #64115 (project make):

  Status:None => Fixed  
 Open/Closed:Open => Closed 
   Fixed Release:None => SCM
   Triage Status:None => Small Effort   

___

Follow-up Comment #2:

Pushed, thanks Dmitry.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #64124] Use after free in expand_variable_buf.

[Paul D. Smith]

Update of bug #64124 (project make):

  Status:None => Fixed  
 Open/Closed:Open => Closed 
   Fixed Release:None => SCM
   Triage Status:None => Small Effort   

___

Follow-up Comment #3:

Pushed thanks Dmitry.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #64107] -R and -r settings in MAKEFLAGS are delayed until build time

[Paul D. Smith]

Follow-up Comment #2, bug #64107 (project make):

This is a good change, thanks!


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #64016] Simplify update_goal_chain.

[Paul D. Smith]

Follow-up Comment #2, bug #64016 (project make):

I installed the code cleanup, thanks.

I don't understand the test that was added though.  How does this test show
that both rules are run at the same time?  It seems like it would behave the
same even if they were not.

Don't you mean something like this:

run_make_test(q!
hello.x::; @#HELPER# -q wait bye.x out $@
bye.x::; @#HELPER# sleep 1 file $@
!,
  '-j2 hello.x bye.x', "sleep 1\nfile bye.x\nhello.x");

?


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/