It indeed crashes with a core dump. I observed this on sunos/gcc when
p+3 points to the next page.
This should be easy to reproduce with a tool like libefence. Another
way to reproduce is to run $(wildcard hello*) in a directory with
thousands of files.

regards, Dmitry

On Tue, Sep 24, 2019 at 1:01 PM Paul Smith <p...@mad-scientist.net> wrote:
>
> On Tue, 2019-09-03 at 04:14 +0000, Dmitry Goncharov via Bug reports and
> discussion for GNU make wrote:
> > sum_up_to_nul reads 4 bytes starting from the passed string 'p'.
> > 'p' can have fewer than 4 bytes. Usually there more allocated space
> > after 'p', which prevents this reading from manifesting itself. This
> > reading manifests itself visibly when 'p' points to the end of the
> > allocated block of memory, such that p + 3 points to not allocated
> > memory.
> > Please have a look at the patch in the attachment.
> > Tested on both big and little endian, 32 and 64 bit.
>
> I understand the issue.  The reason for the "special" code here is
> performance, and unfortunately the solution proposed will reduce
> performance by a measurable amount (not huge but measurable).
>
> Your subject seems to suggest that you got a coredump: can you clarify
> what system / compiler / etc. that was on?  Although obviously it's
> technically invalid to access beyond the end of a string, it typically
> does work without failure (I see no issues on any of my test systems
> for example), unless you're doing something fancy such as shared memory
> etc. where accessing even one byte beyond a boundary could give a
> segmentation fault.  However, GNU make certainly doesn't do anything
> like that.
>
> With "normal" systems it's safe to read (only) memory beyond the end of
> an array, at least up to the next word size, which is what this code
> does.
>

_______________________________________________
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
  • gmake-4.2.90 ... Dmitry Goncharov via Bug reports and discussion for GNU make
    • Re: gmak... Paul Smith
      • Re: ... Dmitry Goncharov via Bug reports and discussion for GNU make
      • Re: ... David A. Wheeler
      • Re: ... Edward Welbourne
        • ... Paul Smith
      • Re: ... Dmitry Goncharov via Bug reports and discussion for GNU make
    • Re: gmak... Paul Smith

Reply via email to