bugmake - Bugs: bug #36925, Memory corruption or use after free

 
 

bug #36925: Memory corruption or use after free

Submitter:  None
Submitted:  Mon 23 Jul 2012 06:14:40 PM UTC
   
 
Severity:  3 - Normal Item Group:  Bug
Status:  Fixed Privacy:  Public
Assigned to:  psmith Open/Closed:  Closed
Component Version:  4.0 Operating System:  POSIX-Based
Fixed Release:  4.0 Triage Status:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Sun 09 Sep 2012 09:57:26 PM UTC, comment #3: 

Thanks for the great test case.  Fix applied.

Paul D. Smith <psmith>
Group administrator
Sat 18 Aug 2012 06:07:32 PM UTC, comment #2: 

More investgation and another example in attached Makefile3.

Some of my earlier assumptions seem inaccurate. I now think this is what's important:
  - Use of second expansion.
  - A defintion of a static pattern rule.
  - A function or variable that's expanded during second expansion that appears anywhere in the prerequisite list.
  - The length of the pattern + prerequisite list exceeds 200 characters.
  - Use of eval to define the rule.

I'm still confused about the behaviour described in my previous comment where I commented out .SECONDEXPANSION, but I think that's probably not related to this bug now.

regards,
Rob.


(file #26382)

Anonymous
Sat 18 Aug 2012 01:44:16 PM UTC, comment #1: 

After more investigation I've created a much simpler example in the attached file Makefile2. With this example the location of the current directory is no longer important.

What is important is the following:
  - Use of second expansion.
  - A function call in the prerequisite list that's expanded during second expansion and that appears around the 200th character in the prerequisite list.
  - The use of eval to define the affected rule.

Building Makefile2 results in the access of freed/uninitialised memory.

I'm not sure if it's related, but while I investigated I commented out the .SECONDEXPANSION line and built the makefile with the -p option. I was expecting the prerequisites of 'all' to contain '$(dir' and '$@)', but instead -p showed prerequistes of '$(dir)' and '$($@)' - note the extra brackets and dollar. Perhaps this is indicative of a problem with the way prerequistes are being parsed that also results in memory problems when second expansion is enabled.

I'll continue to investigate but right now I'm a bit lost trying to understand how the GNU Make code works.

regards,
Rob.

(file #26381)

Anonymous
Mon 23 Jul 2012 06:14:40 PM UTC, original submission:  

I'm seeing memory problems in GNU Make CVS, and I think the 3.82 release is also affected.  I tested the CVS version with Valgrind (using Ubuntu 12.04 as the host OS), and managed to create a couple of small makefiles to demonstrate the problem.

The path of the current directory is significant to the problem.  To reproduce the problem the attached bug.tar.gz archive needs to be extracted to:

/local/gnumake_test/1234567890123456789012345678901234567890

This will create a subdirectory called "bug".  In there you will find a couple of makefiles, "Makefile" and "foo/bar/barf/barf.mak".  There is also a log "valgrind.txt" of the results I get from Valgrind.

To see the problem, change into the "bug" directory and execute the following command (where cvsmake is the make executable):

  env -i valgrind --malloc-fill=0x54 --free-fill=0x55 --tool=memcheck cvsmake -Rr

The problem shows itself with this error from GNU Make:

make: * No rule to make target 'UUUUUU...', needed by 'foo/bar/barf/barf.i'.  Stop.

The UUUUUU... target is not mentioned in any makefile and is a result of GNU Make accessing freed memory (from --free-fill=0x55 valgrind option).

If instead you tell GNU Make to build /dev/null:

  env -i valgrind --malloc-fill=0x54 --free-fill=0x55 --tool=memcheck cvsmake -Rr /dev/null

the GNU Make error is not reported because there is no attempt to built the barf.i target, however Valgrind still shows something is going wrong with memory handling.

If the path to the current directory is reduced in length or the paths mentioned in the makefiles are changed then the problem seems to go away.

I hope you're able to reproduce what I'm seeing.

regards,
Rob.

Anonymous

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #26382:  Makefile3 added by None (454B - application/octet-stream)
file #26381:  Makefile2 added by None (471B - application/octet-stream)
file #26248:  bug.tar.gz added by None (1KiB - application/gzip)

 

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)
  •  

    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 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2012-09-09 psmith StatusNone Fixed
        Assigned toNone psmith
        Open/ClosedOpen Closed
        Fixed ReleaseNone 4.0
    2012-08-18 None Attached File- Added Makefile3, #26382
    2012-08-18 None Attached File- Added Makefile2, #26381
    2012-07-23 None Attached File- Added bug.tar.gz, #26248

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code