Re: gmake-4.2.90 regression (segmentation fault in sum_up_to_nul )

[Dmitry Goncharov]

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 <address@hidden> 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.
>