Re: Git segfaulting in libcrypto.so when trying to clone.

From: Kubilay Kocak <koobs_at_FreeBSD.org>
Date: Wed, 17 Oct 2018 19:06:23 +1100
On 17/10/2018 6:34 pm, Brennan Vincent wrote:
> This also happens in the stock `git` installed from `pkg`, but I have installed it also from `/usr/ports` so I could enable debug symbols and get a proper stacktrace.
> 
> When cloning any https repo (or at least the ones from github that I tried), git segfaults in `git-remote-https`, and the core dump shows the following stack trace:
> 
>    * frame #0: 0x000000080081f36c libc.so.7`strcmp at strcmp.S:46
>      frame #1: 0x0000000800d04f1d libcrypto.so.8`lh_insert [inlined] getrn(lh=<unavailable>, data=0x00000008013aba20) at lhash.c:434
>      frame #2: 0x0000000800d04ebb libcrypto.so.8`lh_insert(lh=0x0000000801359480, data=0x00000008013aba20) at lhash.c:207
>      frame #3: 0x0000000800d0f05e libcrypto.so.8`OBJ_NAME_add(name=0x0000000000000000, type=<unavailable>, data="m\x04") at o_names.c:202
>      frame #4: 0x000000080120ab8d libcrypto.so.9`openssl_add_all_ciphers_int at c_allc.c:83
>      frame #5: 0x000000080120a4b9 libcrypto.so.9`ossl_init_add_all_ciphers_ossl_ [inlined] ossl_init_add_all_ciphers at init.c:216
>      frame #6: 0x000000080120a4b4 libcrypto.so.9`ossl_init_add_all_ciphers_ossl_ at init.c:205
>      frame #7: 0x000000080064de28 libthr.so.3`_pthread_once(once_control=0x000000080128a3b0, init_routine=(libcrypto.so.9`ossl_init_add_all_ciphers_ossl_ at init.c:205)) at thr_once.c:97
>      frame #8: 0x0000000801209b69 libcrypto.so.9`CRYPTO_THREAD_run_once(once=<unavailable>, init=<unavailable>) at threads_pthread.c:113
>      frame #9: 0x0000000801209f67 libcrypto.so.9`OPENSSL_init_crypto(opts=2097228, settings=0x0000000000000000) at init.c:611
>      frame #10: 0x000000080052982d libssl.so.9`OPENSSL_init_ssl(opts=2097152, settings=<unavailable>) at ssl_init.c:197
>      frame #11: 0x0000000800525cb4 libssl.so.9`SSL_CTX_new(meth=0x0000000800b0d1d0) at ssl_lib.c:2883
>      frame #12: 0x00000008004a4a92 libcurl.so.4`___lldb_unnamed_symbol655$$libcurl.so.4 + 2722
>      frame #13: 0x00000008004a935f libcurl.so.4`___lldb_unnamed_symbol671$$libcurl.so.4 + 271
>      frame #14: 0x000000080045b455 libcurl.so.4`___lldb_unnamed_symbol59$$libcurl.so.4 + 405
>      frame #15: 0x00000008004661ca libcurl.so.4`___lldb_unnamed_symbol136$$libcurl.so.4 + 154
>      frame #16: 0x000000080047c436 libcurl.so.4`___lldb_unnamed_symbol259$$libcurl.so.4 + 934
>      frame #17: 0x000000080047bf0e libcurl.so.4`curl_multi_perform + 222
>      frame #18: 0x000000000026a519 git-remote-https`step_active_slots at http.c:1293
>      frame #19: 0x000000000026a596 git-remote-https`run_active_slot(slot=0x00000008012fa4c0) at http.c:1314
>      frame #20: 0x000000000026a9f8 git-remote-https`run_one_slot(slot=0x00000008012fa4c0, results=0x00007fffffffe0f8) at http.c:1509
>      frame #21: 0x000000000026dc6a git-remote-https`http_request(url="https://github.com/emacs-lsp/lsp-mode/info/refs?service=git-upload-pack", result=0x00007fffffffe298, target=0, options=0x00007fffffffe1f0) at http.c:1793
>      frame #22: 0x000000000026ac5b git-remote-https`http_request_reauth(url="https://github.com/emacs-lsp/lsp-mode/info/refs?service=git-upload-pack", result=0x00007fffffffe298, target=0, options=0x00007fffffffe1f0) at http.c:1869
>      frame #23: 0x000000000026ac1c git-remote-https`http_get_strbuf(url="https://github.com/emacs-lsp/lsp-mode/info/refs?service=git-upload-pack", result=0x00007fffffffe298, options=0x00007fffffffe1f0) at http.c:1910
>      frame #24: 0x0000000000264fbd git-remote-https`discover_refs(service="", for_push=0) at remote-curl.c:385
>      frame #25: 0x0000000000263ca2 git-remote-https`get_refs(for_push=0) at remote-curl.c:465
>      frame #26: 0x000000000026361a git-remote-https`cmd_main(argc=3, argv=0x00007fffffffe470) at remote-curl.c:1369
>      frame #27: 0x00000000002707d7 git-remote-https`main(argc=3, argv=0x00007fffffffe470) at common-main.c:45
>      frame #28: 0x000000000026311b git-remote-https`_start(ap=<unavailable>, cleanup=<unavailable>) at crt1.c:76

Hi Brennan,

git gets its HTTP/HTTPS/etc support via curl, so it's likely an issue there.

> Note in particular that we jump from `libcrypto.so.9` to `libcrypto.so.8`... that seems wrong to me, but I'm not an expert.

There have been many instances in the past where software (from 
ports/packages) ends up linked against *both* OpenSSL from base and 
OpenSSL from ports, due to various issues. This is probably a similar issue.

The same problem can occur for anything that base provides, that can 
also be provided by ports, gssapi, ncurses, readline, among others come 
to mind.



> `/lib/libcrypto.so.8` and `/lib/libcrypto.so.9` both exist for me.

If both exist in base, that's interesting (and probably a problem). I 
only have libcrypto.so.8 on a recent (month old) CURRENT build.

The openssl port (which curl can use) provides libcrypto.so.9 (in 
/usr/local/lib)

> I can't reproduce this on a pristine install of 12.0-ALPHA10.
> 

Some more system information might prove useful:

- FreeBSD version issue is reproducible on (uname -a)
- Output of ldd /usr/local/bin/curl
- Using quarterly or latest packages?
- What exact version (PORTVERSION/PORTREVISION) of the package / port?
- Contents of /etc/make.conf, in particular, any value of 
DEFAULT_VERSIONS=ssl (if set)

A cursory search of our Bugzilla doesn't come up with any other similar 
reports for either git or curl

./koobs
Received on Wed Oct 17 2018 - 06:06:29 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:18 UTC