Re: bin/52348: sh (alias.c:271) invokes undefined behaviour

[Robert Elz <kre%munnari.OZ.AU@localhost>]

The following reply was made to PR bin/52348; it has been noted by GNATS.

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: coypu%sdf.org@localhost
Cc: gnats-bugs%NetBSD.org@localhost
Subject: Re: bin/52348: sh (alias.c:271) invokes undefined behaviour
Date: Thu, 29 Jun 2017 13:12:11 +0700

     Date:        Thu, 29 Jun 2017 05:33:05 +0000
     From:        coypu%sdf.org@localhost
     Message-ID:  <20170629053305.GA22727%SDF.ORG@localhost>
 
   | Found something else by writing down an example.
 
 I will see what I can work out about that one (aside from why the tools awk
 does not exist in your system, and yet it is being used - or wants to
 be, same for nbmktemp - those I can't help with....)
 
 However, debugging sh memory management is hit and miss at the best of
 times, it will be pure fluke if I can find anything from that asan output.
 I would need you to be running a DEBUG shell with every possible debug
 flag turned on when it happened (and possibly gdb as well) to have any
 real expectation of finding that one.  At least I know the situation in
 which it was observed, which helps a little.
 
   | It shows the original, too.
 
 Not really.   It shows the error message.   But it tells me where you
 should look, as there are precisely zero uses of anything related to
 aliases while building sh (except compiling the code to process them.)
 
 To be in the alias code, something must be making it happen, and the
 only candidate (I can see) is the file which is your $ENV
 
 That it happened twice. later running a different script, reinforces that.
 
 So, please send me any lines from $ENV that have anything to do with aliases
 (or just the whole thing) - send via private e-mail, it does not need to
 go into the PR!
 
   | I think it doesn't like the negative index use
 
 There is no negative index.   I understand what asan is saying, it
 is being over petty in this particular case, though it is correct, the
 code in alias.c is wrong, and I will fix it (it isn't even a very good
 hash function, not that it needs to be for aliases, most people don't
 have very many.)
 
 What I want to do is find out how the situation which allowed the bug
 to be discovered arose - if it is just "unusual" input, then I just fix
 (or perhaps change is a better word) the code in alias.c and all will
 be fine.   On the other hand, there might be some other bug.   Only seeing
 the actual line that the sh is executing when the error is produced
 will tell me that -- I don't need to be running asan I don't even really,
 I hope, need to run a sh to process your $ENV (or lines from it), all I
 should need is to see it.
 
 kre