Re: Problems with remote repository access via sftp
Martin Michel <martin-eJ/[email protected]> Wed, 16 Nov 2022 21:14:14 +0100
| Newsgroups | gmane.comp.sysutils.backup.dar.support |
|---|---|
| Message-ID | <[email protected]> |
Hi Denis, > looking at the stack at the time of the segfault, we saw this > occurring "below" libcurl in getaddrinfo() call (part of glibc). There > is a bug > in that part that could explain this problem (affecting only > statically linked binaries in multi-threaded context). Interesting. I remember statically compiling against getaddrinfo() from glibc has some issues. Wasn't it the case that those binaries only work if you run them on the same glibc version? In my case it was not about multi-threading though. My workaround back at that time was that I resorted to musl libc, compiled the binary on Alpine Linux and shared it from there. > Beside this possible root cause, I also met a bug due to translated > messages in dar/libdar (which relies on the gettext library/software). > > You can disable it by un-setting the LANG environment variable before > running dar > > unset LANG > ./dar_static ... > > I could not find any error in the translated message regarding the "%" > masks where a wrongly substituted or extra format in a translated > string for example, could pretty lead to a memory corruption. I will > give a deeper view at this next week-end. > > Anyway, if un-setting the LANG variable fixes the issue, this is the > second bug that you hit (gettext), else this is probably the first > (getaddrinfo) one [1] you hit and upgrading glibc that include a fix > for that and recompiling dar_static against it will I hope fix the > issue, if the cause is not yet else. No, un-setting LANG variable did not help, still getting the segfault. > > I still have to test under Void Linux, will do that soon also Note that I am using Void glibc version, there is also a musl one. If the bug is due to the glibc stuff, I would guess, it will work with musl. Best regards, Martin