Re: segfault in git-remote-http
- From
- rh <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.