git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH v1] Travis: also test on 32-bit Linux

From
Jeff King <peff@peff.net>
Date
Mar 5, 2017, 11:36 UTC
Message-ID
<20170305113618.ko2jymle4n5f2b5l@sigill.intra.peff.net>
In-Reply-To
<282895e1-d9eb-2368-a8e7-8085ad9b17ed@oracle.com>
On Sat, Mar 04, 2017 at 09:08:40PM +0100, Vegard Nossum wrote:
Show 9 quoted lines
> > At a glance, looks like range_set_copy() is using
> > sizeof(struct range_set) == 12, but
> > range_set_init/range_set_grow/ALLOC_GROW/REALLOC_ARRAY is using
> > sizeof(rs->range) == 8.
> 
> Attached patch seems to fix it -- basically, range_set_copy() is trying
> to copy more than it should. It was uncovered with the test case from
> Allan's commit because it's creating enough ranges to overflow the
> initial allocation on 32-bit.
Ugh, yeah, that is definitely a bug.
Show 10 quoted lines
> diff --git a/line-log.c b/line-log.c
> index 951029665..cb0dc1110 100644
> --- a/line-log.c
> +++ b/line-log.c
> @@ -43,7 +43,7 @@ void range_set_release(struct range_set *rs)
>  static void range_set_copy(struct range_set *dst, struct range_set *src)
>  {
>  	range_set_init(dst, src->nr);
> -	memcpy(dst->ranges, src->ranges, src->nr*sizeof(struct range_set));
> +	memcpy(dst->ranges, src->ranges, src->nr*sizeof(struct range));

I think "sizeof(*dst->ranges)" is probably an even better fix, as it infers the type of "dst". But these days we have COPY_ARRAY() to make it even harder to get this kind of thing wrong.

I grepped for 'memcpy.*sizeof' and found one other case that's not a bug, but is questionable.

Of the "good" cases, I think most of them could be converted into something more obviously-correct, which would make auditing easier. The three main cases I saw were:

  1. Ones which can probably be converted to COPY_ARRAY().
  2. Ones which just copy a single object, like:
       memcpy(&dst, &src, sizeof(dst));
     Perhaps we should be using struct assignment like:
       dst = src;
     here. It's safer and it should give the compiler more room to
     optimize. The only downside is that if you have pointers, it is
     easy to write "dst = src" when you meant "*dst = *src".
  3. There were a number of alloc-and-copy instances. The copy part is
     the same as (2) above, but you have to repeat the size, which is
     potentially error-prone. I wonder if we would want something like:
       #define ALLOC_COPY(dst, src) do { \
         (dst) = xmalloc(sizeof(*(dst))); \
	 COPY_ARRAY(dst, src, 1); \
       while(0)
     That avoids having to specify the size at all, and triggers a
     compile-time error if "src" and "dst" point to objects of different
     sizes.
     I suspect our friendly neighborhood coccinelle wizards could cook
     up a conversion.
-Peff
Previous: Vegard NossumNext: Jeff King
Message 18 of 36 in “Travis: also test on 32-bit Linux”
  1. Travis: also test on 32-bit LinuxJohannes Schindelin, Feb 28, 2017
  2. Johannes SchindelinFeb 28, 2017
  3. Junio C HamanoMar 2, 2017
  4. Travis: also test on 32-bit LinuxLars Schneider, Mar 2, 2017
  5. Johannes SchindelinMar 2, 2017
  6. Lars SchneiderMar 2, 2017
  7. Johannes SchindelinMar 2, 2017
  8. Christian CouderMar 2, 2017
  9. Junio C HamanoMar 2, 2017
  10. Johannes SchindelinMar 3, 2017
  11. Junio C HamanoMar 3, 2017
  12. Junio C HamanoMar 4, 2017
  13. Junio C HamanoMar 4, 2017
  14. Lars SchneiderMar 4, 2017
  15. Vegard NossumMar 4, 2017
  16. Vegard NossumMar 4, 2017
  17. Vegard NossumMar 4, 2017
  18. Jeff KingMar 5, 2017
  19. line-log: use COPY_ARRAY to fix mis-sized memcpyJeff King, Mar 5, 2017
  20. Vegard NossumMar 5, 2017
  21. Jeff KingMar 5, 2017
  22. René ScharfeMar 10, 2017
  23. Jeff KingMar 10, 2017
  24. René ScharfeMar 10, 2017
  25. Jeff KingMar 10, 2017
  26. René ScharfeMar 10, 2017
  27. Jeff KingMar 10, 2017
  28. René ScharfeMar 10, 2017
  29. Junio C HamanoMar 10, 2017
  30. Jeff KingMar 10, 2017
  31. René ScharfeMar 10, 2017
  32. Junio C HamanoMar 10, 2017
  33. René ScharfeMar 11, 2017
  34. Ramsay JonesMar 2, 2017
  35. Lars SchneiderMar 5, 2017
  36. Ramsay JonesMar 5, 2017

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.