I was not able to reproduce it with Make 4.1 or Make 4.3.
I don't have the original Make 4.4.1, but I had a binary of my fork 4.4.1h2
from https://github.com/henca/Henriks-make and got a segfault in that one
which probably means that I have been able to reproduce the report from Miao.
Opening a core dump i ddd it seems as if the segfault was at:
src/expand.c:119
called from variable.c:1143
called from function.c:1878
called from function.c:2693
called from expand.c:282
called from expand.c:441
called from expand.c:448
called from expand.c:590
...
Or copy paste from the debugger:
Core was generated by `./make'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 recursively_expand_for_file (v=v@entry=0x13e5990, file=file@entry=0x0)
at src/expand.c:119
(gdb) bt
#0 recursively_expand_for_file (v=v@entry=0x13e5990, file=file@entry=0x0) at
#src/expand.c:119 1 0x0000000000429bad in target_environment
#(file=file@entry=0x0, recursive=recursive@entry=0) at src/variable.c:1143 2
#0x00000000004133dc in func_shell_base (o=0x13f2680 "", argv=<optimized out>,
#trim_newlines=1) at src/function.c:1878 3 0x0000000000413923 in
#handle_function (op=op@entry=0x7ffd1edc1428,
#stringp=stringp@entry=0x7ffd1edc1420) at src/function.c:2693 4
#0x000000000040d3c2 in variable_expand_string (line=<optimized out>,
#line@entry=0x0, string=<optimized out>,
#length=length@entry=18446744073709551615) at src/expand.c:282 5
#0x000000000040db5e in variable_expand (line=<optimized out>) at
#src/expand.c:441 6 variable_expand_for_file (file=0x0, line=<optimized out>)
#at src/expand.c:488 7 allocated_variable_expand_for_file (file=0x0,
#line=<optimized out>) at src/expand.c:590 8 recursively_expand_for_file
#(v=v@entry=0x13e5990, file=file@entry=0x13e5a30) at src/expand.c:164 9
#0x0000000000429bad in target_environment (file=<optimized out>,
#recursive=<optimized out>) at src/variable.c:1143 10 0x00000000004188d2 in
#start_job_command (child=child@entry=0x13f25c0) at src/job.c:1431 11
#0x00000000004192d4 in start_waiting_job (c=c@entry=0x13f25c0) at
#src/job.c:1646 12 0x0000000000419cf2 in new_job (file=0x13e5a30) at
#src/job.c:1960 13 0x0000000000425a95 in remake_file (file=0x13e5a30) at
#src/remake.c:1313 14 update_file_1 (depth=<optimized out>, file=<optimized
#out>) at src/remake.c:905 15 update_file (file=file@entry=0x13e5a30,
#depth=<optimized out>) at src/remake.c:367 16 0x00000000004263e1 in
#update_goal_chain (goaldeps=<optimized out>) at src/remake.c:184 17
#0x0000000000409045 in main (argc=<optimized out>, argv=<optimized out>,
#envp=<optimized out>) at src/main.c:2951
(gdb)
Looking at the variables in ddd I see that *ep is a string "VDPAU_LOG=0"
probably taken from my environment. The variable nl is 41 which is way beyond
that string and probably causing the segfault. The nl variable comes from
strlen(v->name) where v->name is "THIS_LONG_VARIABLE_NAME_PRODUCE_THE_ERROR".
So it seems to me that such a long variable name can cause a segfault if an
environment variable is short enough.
I realize a report like this would be more valuable if I had the original gnu
make. On my fork I have modified main.c and job.c (and posixos.c) making any
line numbers from those files not trustworthy. However, I still hope that my
analysis will be useful.
regards Henrik
On Mon, 15 Jan 2024 14:37:31 -0500
Paul Smith <psm...@gnu.org> wrote:
> On Mon, 2024-01-15 at 11:21 +0000, MIAOW Miao wrote:
> > I found name of exported resursively expanded variable with $(shell
> > ...) cannot be too long in gnu make version >= 4.4, otherwise a
> > segmentation fault is triggled. I'm not sure if variable-name-too-
> > long is a bug. However, make is
> > supposed to tell me what's going wrong.
> >
> > Here is a Makefile that can reproduce the segmentation fault:
> > > THIS_LONG_VARIABLE_NAME_PREDUCE_THE_ERROR= $(shell echo hello)
> > > exportTHIS_LONG_VARIABLE_NAME_PREDUCE_THE_ERROR
> > >
> > > all: ; echo "abc"
>
> I was not able to reproduce this problem, either with my own build of
> GNU Make 4.4.1 or with a binary extracted from the RPM from the link
> you provided. I tried running under valgrind and with a binary
> compiled with ASAN, with and withoug debugging enabled, ran the test
> 1000 times. I also tried GNU Make 4.4.
>
> If you can generate a coredump please examine it with GDB and send
> along at least the backtrace.
>
> --
> Paul D. Smith <psm...@gnu.org> Find some GNU make tips at:
> https://www.gnu.org http://make.mad-scientist.net
> "Please remain calm...I may be mad, but I am a professional." --Mad
> Scientist
>
