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

Re: Memory corruption when rebasing with git version 1.8.1.5 on arch

From
BPBernhard Posselt <mail@bernhard-posselt.com>
Date
Mar 19, 2013, 10:42 UTC
Message-ID
<51484125.9000307@bernhard-posselt.com>
In-Reply-To
<20130311051840.GB13510@sigill.intra.peff.net>
Ok, sorrry for not responsding for quite a while, we had the 5.0 release and had too much to do.
I found out why it segfaults: I had a .gitconfig file (sry must have somehow missed that no idea why actually) with the following contents:
http://dpaste.com/1027662/
it seems that the memory corruption does not happen anymore when i change
[apply]
         whitespace = fix
to
[apply]
         #whitespace = fix
so fixing whitespaces may be the culprit
On 03/11/2013 06:18 AM, Jeff King wrote:
Show 29 quoted lines
> On Sun, Mar 10, 2013 at 12:45:43PM +0100, Bernhard Posselt wrote:
>
>>>    valgrind -q --trace-children=yes --log-file=/tmp/valgrind.out \
>>>      git pull --rebase https://github.com/Raydiation/core
>> The log file was empty and it seemed to apply everything nice when
>> running valgrind. When i tried to run it without valgrind it failed
>> with memory corruption.
> Thanks, we are maybe getting closer. It's weird that it works OK with
> valgrind. If the valgrind log is empty, though, I'm confused about where
> the output you pasted below came from.
>
>> ==22291== Invalid write of size 1
>> ==22291==    at 0x4C2DB93: memcpy@@GLIBC_2.14 (in
>> /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
>> ==22291==    by 0x4076B1: update_pre_post_images (in /usr/lib/git-core/git)
>> ==22291==    by 0x40A60F: apply_fragments (in /usr/lib/git-core/git)
>> ==22291==    by 0x40C29F: check_patch_list (in /usr/lib/git-core/git)
>> ==22291==    by 0x40CC35: apply_patch (in /usr/lib/git-core/git)
>> ==22291==    by 0x40F584: cmd_apply (in /usr/lib/git-core/git)
>> ==22291==    by 0x4058E7: handle_internal_command (in /usr/lib/git-core/git)
>> ==22291==    by 0x404DD1: main (in /usr/lib/git-core/git)
> Hmm, it would be nice to have line numbers. Can you try compiling with
> "-g -O0"?
>
> The function where the problem is deals with whitespace munging. Just a
> guess, but do you have any whitespace config options set (e.g.,
> apply.whitespace)?
>
> -Peff
Previous: Jeff KingNext: Jeff King
Message 10 of 14 in “Memory corruption when rebasing with git version 1.8.1.5 on arch”
  1. Bernhard PosseltMar 8, 2013
  2. Jeff KingMar 8, 2013
  3. Bernhard PosseltMar 9, 2013
  4. Jeff KingMar 9, 2013
  5. Bernhard PosseltMar 9, 2013
  6. Jeff KingMar 10, 2013
  7. Bernhard PosseltMar 10, 2013
  8. Bernhard PosseltMar 10, 2013
  9. Jeff KingMar 11, 2013
  10. Bernhard PosseltMar 19, 2013
  11. Jeff KingMar 19, 2013
  12. Junio C HamanoMar 19, 2013
  13. Junio C HamanoMar 22, 2013
  14. Jeff KingMar 22, 2013

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.