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

[Edward Welbourne]

On Tue, 2019-09-03 at 04:14 +0000, Dmitry Goncharov 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.

Usually malloc aligns its allocations on word boundaries, since the
caller typically needs that.  It also typically rounds up all
allocations to a whole number of words, since it can't represent the
residue from a partial word in its free list.  So usually the allocation
ends on a word boundary, even if what was asked for didn't.  Thus if the
iteration that's reading four bytes at a time starts at the allocation's
start, this should usually be safe.

Not that it's good practice to rely on this, though ...

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

Did the scan start from part way through an allocated string ?  That
could put it at a non-word-aligned offset from the allocation's start.

>> Please have a look at the patch in the attachment.
>> Tested on both big and little endian, 32 and 64 bit.

Paul Smith (24 September 2019 18:38) replied:
> 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).

[snip]

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

If you want to be able to rely on this "normal" behaviour, for the sake
of the performance benefit it gives you, you need to add three to every
call to malloc, so as to make it well-defined.  Of course, that shall
increase memory use by a measurable amount (not huge, but measurable).

        Eddy.