From: Junio C Hamano <gitster@pobox.com>
To: "Kyle J. McKay" <mackyle@gmail.com>
Cc: Jeff King <peff@peff.net>, git@vger.kernel.org
Subject: Re: [PATCH] pack-bitmap: do not core dump
Date: Tue, 22 Apr 2014 16:11:28 -0700 [thread overview]
Message-ID: <xmqq7g6h2c4f.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <781073ea08e86301f62e708bc0b80fd@74d39fa044aa309eaea14b9f57fe79c> (Kyle J. McKay's message of "Tue, 22 Apr 2014 15:53:02 -0700")
"Kyle J. McKay" <mackyle@gmail.com> writes:
> So I was trying to use pack.writebitmaps=true and all I got was core dumps.
>
> The fix with a real subject line ;) is below. I think perhaps this should be
> picked up for the 2.0.0 release. (Patch is against master.)
Of course---a breakage in a new code may be less important than a
regression fix in the sense that there is an option not to use the
new feature, but an obvious fix to such a breakage is certainly very
much welcomed during the -rc period.
Thanks. I'll try not to forget until tomorrow's integration cycle
(I just finished and pushed the results out for today), which will
also give me a chance to wait for Peff's Ack ;-).
> --Kyle
>
> ---- >8 ----
> Subject: [PATCH] ewah_bitmap.c: do not assume size_t and eword_t are the same size
>
> When buffer_grow changes the size of the buffer using realloc,
> it first computes and saves the rlw pointer's offset into the
> buffer using (uint8_t *) math before the realloc but then
> restores it using (eword_t *) math.
>
> In order to do this it's necessary to convert the (uint8_t *)
> offset into an (eword_t *) offset. It was doing this by
> dividing by the sizeof(size_t). Unfortunately sizeof(size_t)
> is not same as sizeof(eword_t) on all platforms.
>
> This causes illegal memory accesses and other bad things to
> happen when attempting to use bitmaps on those platforms.
>
> Fix this by dividing by the sizeof(eword_t) instead which
> will always be correct for all platforms.
>
> Signed-off-by: Kyle J. McKay <mackyle@gmail.com>
> ---
> ewah/ewah_bitmap.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/ewah/ewah_bitmap.c b/ewah/ewah_bitmap.c
> index 9ced2dad..fccb42b5 100644
> --- a/ewah/ewah_bitmap.c
> +++ b/ewah/ewah_bitmap.c
> @@ -41,7 +41,7 @@ static inline void buffer_grow(struct ewah_bitmap *self, size_t new_size)
> self->alloc_size = new_size;
> self->buffer = ewah_realloc(self->buffer,
> self->alloc_size * sizeof(eword_t));
> - self->rlw = self->buffer + (rlw_offset / sizeof(size_t));
> + self->rlw = self->buffer + (rlw_offset / sizeof(eword_t));
> }
>
> static inline void buffer_push(struct ewah_bitmap *self, eword_t value)
next prev parent reply other threads:[~2014-04-22 23:11 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-22 22:53 [PATCH] pack-bitmap: do not core dump Kyle J. McKay
2014-04-22 23:11 ` Junio C Hamano [this message]
2014-04-22 23:17 ` Jeff King
2014-04-23 0:40 ` Kyle J. McKay
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqq7g6h2c4f.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=mackyle@gmail.com \
--cc=peff@peff.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.