bug-make
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #45275] 4.0+ core dumps with long .PHONY targets via variables


From: David Boyce
Subject: [bug #45275] 4.0+ core dumps with long .PHONY targets via variables
Date: Mon, 08 Jun 2015 13:45:46 +0000
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.81 Safari/537.36

URL:
  <http://savannah.gnu.org/bugs/?45275>

                 Summary: 4.0+ core dumps with long .PHONY targets via
variables
                 Project: make
            Submitted by: boyski
            Submitted on: Mon 08 Jun 2015 01:45:44 PM GMT
                Severity: 3 - Normal
              Item Group: Bug
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
       Component Version: 4.1
        Operating System: POSIX-Based
           Fixed Release: None
           Triage Status: None

    _______________________________________________________

Details:

I've isolated a bug in which make 4.x segfaults when a phony target name is
longer than 8162 characters. I'll attach the test case. I haven't tracked down
the coding problem but I do have some useful data:

1. This is a regression: it does not occur in 3.82 but does in 4.0 and 4.1.

2. At least in my environment it occurs when the target is 8163 characters or
longer. This number is not a factor of 2 though it's fairly close to 8192.

3. Interestingly, if the phony target is converted to a real target e.g.

<long string>: ; date

Then the result is "make: stat <long string>: File name too long

(with exit status of 0 which may be an ancillary bug). Technically a phony
target shouldn't be subject to the same length limits as an actual target
since nothing is imposed by the OS/filesystem. It may be acceptable to impose
those limits anyway but the core dump shouldn't occur.

4. Running under gdb I was able to get a stack trace showing the eventual seg
fault occurring in xcalloc(). The trace is below.

Program received signal SIGSEGV, Segmentation fault.
0x0000003a17a799b3 in _int_malloc () from /lib64/libc.so.6
(gdb) bt
#0  0x0000003a17a799b3 in _int_malloc () from /lib64/libc.so.6
#1  0x0000003a17a7a5a6 in calloc () from /lib64/libc.so.6
#2  0x000000000041ca6a in xcalloc (size=136) at misc.c:231
#3  0x000000000040aea5 in enter_file (name=0x65a4b1 'X' <repeats 2048
times>...) at file.c:185
#4  0x000000000040bdaf in enter_prereqs (deps=0x654e50, stem=0x0) at
file.c:538
#5  0x0000000000422072 in record_files (filenames=0x663920, pattern=0x0,
pattern_percent=0x0, depstr=0x6659c0 "h\365\330\027:",
    cmds_started=1, commands=0x663850 "\030\366\330\027:", commands_idx=0,
two_colon=0, prefix=9 '\t', flocp=0x7fffffff6880)
    at read.c:2000
#6  0x000000000041fc22 in eval (ebuf=0x7fffffff6a60, set_default=1) at
read.c:1013
#7  0x000000000041e958 in eval_makefile (filename=0x65a47d "Makefile",
flags=0) at read.c:445
#8  0x000000000041e3b7 in read_all_makefiles (makefiles=0x0) at read.c:262
#9  0x0000000000419434 in main (argc=2, argv=0x7fffffffc688,
envp=0x7fffffffc6a0) at main.c:1895
#10 0x0000003a17a1ecdd in __libc_start_main () from /lib64/libc.so.6
#11 0x0000000000405f49 in _start ()



    _______________________________________________________

File Attachments:


-------------------------------------------------------
Date: Mon 08 Jun 2015 01:45:44 PM GMT  Name: Makefile.gz  Size: 80B   By:
boyski

<http://savannah.gnu.org/bugs/download.php?file_id=34178>

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?45275>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]