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

Re: segfault in git-remote-http

From
Rrh <richard_hubbe11@lavabit.com>
Date
Apr 13, 2013, 01:01 UTC
Message-ID
<20130412180135.ab642b784f754ff627bd6602@lavabit.com>
In-Reply-To
<20130410191103.GA22914@sigill.intra.peff.net>

On Wed, 10 Apr 2013 15:11:03 -0400 Jeff King <peff@peff.net> wrote:

Show 37 quoted lines
> On Wed, Apr 10, 2013 at 02:51:14PM -0400, Jeff King wrote:
> 
> > As for why dmesg reports git-remote-http, I'm not sure. If you
> > "strace -f" the command, you can see that git is running
> > git-remote-https. Why the kernel chooses to report
> > "git-remote-http", I don't know; you'd have to look into how the
> > kernel makes that decision. But I doubt it is related to the reason
> > for the segfault in the first place.
> 
> Ah, I see. The hard links are a red herring. The kernel's message uses
> task->comm, which is presumably set by truncating the basename of the
> program to 15 characters (16 bytes with a trailing NUL).
> 
>   3.6 /proc/<pid>/comm  & /proc/<pid>/task/<tid>/comm
>   --------------------------------------------------------
>   These files provide a method to access a tasks comm value. It also
>   allows for a task to set its own or one of its thread siblings comm
>   value. The comm value is limited in size compared to the cmdline
>   value, so writing anything longer then the kernel's TASK_COMM_LEN
>   (currently 16 chars) will result in a truncated comm value.
> 
> Try:
> 
>   $ echo 'int main() { sleep(5); *(int *)0=0; }' >foo.c
>   $ gcc -o 12345678901234567890 foo.c
>   $ ./123* &
>   $ cat /proc/$!/comm
>   123456789012345
>   $ sleep 5; dmesg | tail -n 1
>   [2602639.353584] 123456789012345[23062]: segfault at 0 ip
> 0000000000400524 sp 00007fff46bb0700 error 6 in 12345678901234567890
> [400000+1000]
> 
> In both cases we only get the first 15 bytes of the program name. And
> indeed, "git-remote-http" is exactly 15 bytes. So it is dumb luck that
> the limit is such that truncating the name makes it look like another
> program.

I realize this is not real critical but these three would all suffer the same fate on segfault. i.e. the kernel would report git-credential- as the app that suffered the seg fault.

git-credential-cache git-credential-cache--daemon git-credential-store

For sake of completeness on this thread if nothing else.
Previous: rhNext: rh
Message 15 of 17 in “segfault in git-remote-http”
  1. rhApr 7, 2013
  2. rhApr 7, 2013
  3. rhApr 9, 2013
  4. Jeff KingApr 9, 2013
  5. Daniel StenbergApr 9, 2013
  6. rhApr 12, 2013
  7. rhApr 9, 2013
  8. Jeff KingApr 9, 2013
  9. rhApr 9, 2013
  10. Jeff KingApr 10, 2013
  11. rhApr 10, 2013
  12. Jeff KingApr 10, 2013
  13. Jeff KingApr 10, 2013
  14. rhApr 10, 2013
  15. rhApr 13, 2013
  16. rhApr 10, 2013
  17. Jeff KingApr 10, 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.