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
_______________________________________________
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
