On Wed, Apr 10, 2013 at 09:08:50AM -0700, rh wrote:
which should show both program names. Git invokes git-remote-* based
on the URL you fed it. So if you are seeing a segfault in
git-remote-http, presumably you fed it an http URL (which may still
execute SSL code if it redirects
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
On Wed, Apr 10, 2013 at 12:16:25PM -0700, rh wrote:
This returns no error on the command line and produced the segfault
reported by the kernel. git clone returns immediately.
It does correctly report a failed exit code. The lack of message is
because git assumes that the helper will
On Tue, Apr 09, 2013 at 08:47:18AM -0700, rh wrote:
The symptoms that this patch addresses look similar:
http://article.gmane.org/gmane.mail.postfix.user/217790
Quote from that thread:
This behavior is actually documented (SSL_set_fd() destroys
a BIO already on the SSL handle, and
On Tue, 9 Apr 2013, Jeff King wrote:
git-remote-http does not touch the openssl code itself at all. We only talk
to curl, which handles all of the ssl (and may even be built on gnutls). So
if that is the problem, then I think it may be a libcurl bug, not a git one.
... and if/when you do
On Tue, Apr 09, 2013 at 10:41:34AM -0700, rh wrote:
git-remote-http does not touch the openssl code itself at all. We only
talk to curl, which handles all of the ssl (and may even be built on
gnutls). So if that is the problem, then I think it may be a libcurl
bug, not a git one.
clear in my initial reportand may have omitted a
significant fact. The git clone returned right away and I saw no
error. The error shows up in dmesg via syslog, something like
git-remote-http[1234]: segfault at blah blah in libcrypto
That message is not generated by git, but rather
7 matches
Mail list logo
