[Top][All Lists]

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

[bug #43221] Random string corruption when recursively evaluating guile

From: Taahir Ahmed
Subject: [bug #43221] Random string corruption when recursively evaluating guile code.
Date: Sun, 14 Sep 2014 07:38:50 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0


                 Summary: Random string corruption when recursively evaluating
guile code.
                 Project: make
            Submitted by: ahmedtd
            Submitted on: Sun 14 Sep 2014 07:38:49 AM GMT
                Severity: 3 - Normal
              Item Group: Bug
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
       Component Version: 4.0
        Operating System: POSIX-Based
           Fixed Release: None
           Triage Status: None



I am working on a build system that extensively uses GNU Make's new guile
integration.  One of my goals is to simplify the creation and use of
non-recursive makefiles (in the Recursive Make Considered Harmful sense).

I created a guile function (augmk/enter) that sets up some automatic
bookkeeping and then executes 'include <subdir>/Rules.mk' using gmk-eval. 
This seems to mostly work, but under certain conditions causes random

I have attached an example project that shows random string corruption on two
different systems.  If you run 'make clean' from the top-level project
directory, the expected output is something like:

$ make clean
rm -rf aaaaaaaaaaaaaaaaa
rm -rf bbbbbbbbbbbbbbbbb
rm -rf hhhhhhhhhhhhhhhhh

However, most of the time, one of the output lines will be something like

rm -rf <blank>
rm -rf <utf-8 nonsense>
rm -rf r/share/.... <some actual path from /usr on my system, but with the
leading "/us" cut off>

Removing any of these factors from the example project causes the corruption
to go away:

  1) Making the targets in question 16 characters or less.
  2) Not emitting the code for the 'clean' target from guile, but instead
putting it directly in ./Rules.mk.
  3) Not including each Rules.mk file from guile (via augmk/enter), but rather
directly writing 'include <subdir>/Rules.mk.

I can reproduce this corruption using both Make 4.0 (from the Gentoo
repositories) and with the latest master checkin from git.

I suspect that the "real" part of the problem comes from calling 'include'
from within guile.

I've tried one mitigation strategy already, to no effect: in guile.c, use
scm_without_guile() to ensure that eval() is never called in guile mode.


File Attachments:

Date: Sun 14 Sep 2014 07:38:49 AM GMT  Name: example.tar.gz  Size: 1kB   By:
A small example project that reproduces the error.


Reply to this item at:


  Message sent via/by Savannah

reply via email to

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