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

 
 

bug #36925: Memory corruption or use after free

Submitted by:  None
Submitted on:  Mon 23 Jul 2012 06:14:40 PM UTC  
 
Severity: 3 - NormalItem Group: Bug
Status: FixedPrivacy: Public
Assigned to: Paul D. Smith <psmith>Open/Closed: Closed
Component Version: 4.0Operating System: POSIX-Based
Fixed Release: 4.0Triage Status: None

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

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

Thanks for the great test case. Fix applied.

Paul D. Smith <psmith>
Project AdministratorIn charge of this item.
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 File(s):
   
   
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
  • -unavailable- added by psmith (Posted a comment)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 7 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sun 09 Sep 2012 09:57:26 PM UTCpsmithStatusNone=>Fixed
      Assigned toNone=>psmith
      Open/ClosedOpen=>Closed
      Fixed ReleaseNone=>4.0
    Sat 18 Aug 2012 06:07:32 PM UTCNoneAttached File-=>Added Makefile3, #26382
    Sat 18 Aug 2012 01:44:16 PM UTCNoneAttached File-=>Added Makefile2, #26381
    Mon 23 Jul 2012 06:14:40 PM UTCNoneAttached File-=>Added bug.tar.gz, #26248

    Back to the top


    Powered by Savane 3.1-cleanup1