| Summary: | kio_sftp doesn't work until wiping kdeglobals config | ||
|---|---|---|---|
| Product: | [Frameworks and Libraries] kio-extras | Reporter: | Vadim A. Misbakh-Soloviov (mva) <kde> |
| Component: | SFTP | Assignee: | Andreas Schneider <asn> |
| Status: | RESOLVED FIXED | ||
| Severity: | major | CC: | adawit, mieszcz, rakuco, simonandric5 |
| Priority: | NOR | ||
| Version: | 18.04.3 | ||
| Target Milestone: | --- | ||
| Platform: | Gentoo Packages | ||
| OS: | Linux | ||
| Latest Commit: | http://commits.kde.org/kde-runtime/3dc39e92d34b3612e90f7a0b34d5d845a7af0b72 | Version Fixed In: | |
| Sentry Crash Report: | |||
| Attachments: |
valgrin.log
additional valgrind log Proposed patch |
||
kio_sftp does not use Firefox profile. It cannot run because something that does use it has taken all the memory. That is what the error message clearly states. kio_sftp cannot be started because you are out of memory. The only thing I could find in the source code that does mess around with Firefox's profile is a one of Plasma's runners that attempts to read the list of bookmarks from Firefox??
kde-workspace/plasma/generic/runners/bookmarks/browsers/firefox.cpp: m_dbCacheFile = KStandardDirs::locateLocal("cache", "") + "bookmarkrunnerfirefoxdbfile.sqlite";
kde-workspace/plasma/generic/runners/bookmarks/browsers/firefox.cpp: m_dbFile = grp.readEntry<QString>("dbfile", "");
kde-workspace/plasma/generic/runners/bookmarks/browsers/firefox.cpp: grp.writeEntry("dbfile", m_dbFile);
Anyhow, this is not a kio_sftp issue at all.
Hi, Dawit!
1) thank you for investigation!
okay, we've found that "db=firefox_profile" isn't kio_sftp issue, thanks. But,
2) as I said, main issue is in that fact, that it is 16 (!) GB RAM, with at least 10-14 of them absolutelly free (I even tried to wipe fs cache), but kio_sftp complains on memory. And, as I said, wiping the kdeglobals config makes it to work (until kdeglobals filled back). So, I swear, it is not an
> It cannot run because something that does use it has taken all the memory.
issue (until you mean not a total RAM capacity, but some limits).
The "Error. Out of memory." "Could not set a timeout." This is really really strange. The timeout is an integer we try to specify and if this doesn't work, we probably have a memory corruption. So we need to have a valgrind log for this. http://techbase.kde.org/Development/Tutorials/Debugging/Debugging_IOSlaves#Debugging_io-slaves_with_valgrind Ok. Here is the valgrind log with working kio_sftp. I'll try to get next (when it will not) in few moments. ==19861== Memcheck, a memory error detector ==19861== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==19861== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info ==19861== Command: /usr/lib64/kde4/libexec/kioslave /usr/lib64/kde4/kio_sftp.so sftp local:/tmp/ksocket-mva/klauncherT20149.slave-socket local:/tmp/ksocket-mva/dolphins20182.slave-socket ==19861== ==19862== Memcheck, a memory error detector ==19862== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==19862== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info ==19862== Command: /usr/lib64/kde4/libexec/kioslave /usr/lib64/kde4/kio_sftp.so sftp local:/tmp/ksocket-mva/klauncherT20149.slave-socket local:/tmp/ksocket-mva/dolphinJ20182.slave-socket ==19862== ==19861== Jump to the invalid address stated on the next line ==19861== at 0x626: ??? ==19861== by 0x400588C: open_verify (in /lib64/ld-2.17.so) ==19861== by 0x4008631: _dl_map_object (in /lib64/ld-2.17.so) ==19861== by 0x400C471: openaux (in /lib64/ld-2.17.so) ==19861== by 0x400E9C5: _dl_catch_error (in /lib64/ld-2.17.so) ==19861== by 0x400C6A2: _dl_map_object_deps (in /lib64/ld-2.17.so) ==19861== by 0x4003608: dl_main (in /lib64/ld-2.17.so) ==19861== by 0x4015307: _dl_sysdep_start (in /lib64/ld-2.17.so) ==19861== by 0x4004EC0: _dl_start (in /lib64/ld-2.17.so) ==19861== by 0x4001637: ??? (in /lib64/ld-2.17.so) ==19861== by 0x4: ??? ==19861== by 0xFFEFFE3D2: ??? ==19861== Address 0x626 is not stack'd, malloc'd or (recently) free'd ==19861== ==19861== ==19861== Process terminating with default action of signal 11 (SIGSEGV) ==19861== Bad permissions for mapped region at address 0x626 ==19861== at 0x626: ??? ==19861== by 0x400588C: open_verify (in /lib64/ld-2.17.so) ==19861== by 0x4008631: _dl_map_object (in /lib64/ld-2.17.so) ==19861== by 0x400C471: openaux (in /lib64/ld-2.17.so) ==19861== by 0x400E9C5: _dl_catch_error (in /lib64/ld-2.17.so) ==19861== by 0x400C6A2: _dl_map_object_deps (in /lib64/ld-2.17.so) ==19861== by 0x4003608: dl_main (in /lib64/ld-2.17.so) ==19861== by 0x4015307: _dl_sysdep_start (in /lib64/ld-2.17.so) ==19861== by 0x4004EC0: _dl_start (in /lib64/ld-2.17.so) ==19861== by 0x4001637: ??? (in /lib64/ld-2.17.so) ==19861== by 0x4: ??? ==19861== by 0xFFEFFE3D2: ??? ==19861== ==19861== HEAP SUMMARY: ==19861== in use at exit: 0 bytes in 0 blocks ==19861== total heap usage: 0 allocs, 0 frees, 0 bytes allocated ==19861== ==19861== All heap blocks were freed -- no leaks are possible ==19861== ==19861== For counts of detected and suppressed errors, rerun with: -v ==19861== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 2) ==19863== Memcheck, a memory error detector ==19863== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==19863== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info ==19862== Jump to the invalid address stated on the next line ==19863== Command: /usr/lib64/kde4/libexec/kioslave /usr/lib64/kde4/kio_sftp.so sftp local:/tmp/ksocket-mva/klauncherT20149.slave-socket local:/tmp/ksocket-mva/dolphinp20182.slave-socket ==19863== ==19862== at 0x626: ??? ==19862== by 0x400588C: open_verify (in /lib64/ld-2.17.so) ==19862== by 0x4008631: _dl_map_object (in /lib64/ld-2.17.so) ==19862== by 0x400C471: openaux (in /lib64/ld-2.17.so) ==19862== by 0x400E9C5: _dl_catch_error (in /lib64/ld-2.17.so) ==19862== by 0x400C6A2: _dl_map_object_deps (in /lib64/ld-2.17.so) ==19862== by 0x4003608: dl_main (in /lib64/ld-2.17.so) ==19862== by 0x4015307: _dl_sysdep_start (in /lib64/ld-2.17.so) ==19862== by 0x4004EC0: _dl_start (in /lib64/ld-2.17.so) ==19862== by 0x4001637: ??? (in /lib64/ld-2.17.so) ==19862== by 0x4: ??? ==19862== by 0xFFEFFE3D2: ??? ==19862== Address 0x626 is not stack'd, malloc'd or (recently) free'd ==19862== ==19862== ==19862== Process terminating with default action of signal 11 (SIGSEGV) ==19862== Bad permissions for mapped region at address 0x626 ==19862== at 0x626: ??? ==19862== by 0x400588C: open_verify (in /lib64/ld-2.17.so) ==19862== by 0x4008631: _dl_map_object (in /lib64/ld-2.17.so) ==19862== by 0x400C471: openaux (in /lib64/ld-2.17.so) ==19862== by 0x400E9C5: _dl_catch_error (in /lib64/ld-2.17.so) ==19862== by 0x400C6A2: _dl_map_object_deps (in /lib64/ld-2.17.so) ==19862== by 0x4003608: dl_main (in /lib64/ld-2.17.so) ==19862== by 0x4015307: _dl_sysdep_start (in /lib64/ld-2.17.so) ==19862== by 0x4004EC0: _dl_start (in /lib64/ld-2.17.so) ==19862== by 0x4001637: ??? (in /lib64/ld-2.17.so) ==19862== by 0x4: ??? ==19862== by 0xFFEFFE3D2: ??? ==19862== ==19862== HEAP SUMMARY: ==19862== in use at exit: 0 bytes in 0 blocks ==19862== total heap usage: 0 allocs, 0 frees, 0 bytes allocated ==19862== ==19862== All heap blocks were freed -- no leaks are possible ==19862== ==19862== For counts of detected and suppressed errors, rerun with: -v ==19862== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 2) ==19863== Jump to the invalid address stated on the next line ==19863== at 0x626: ??? ==19863== by 0x400588C: open_verify (in /lib64/ld-2.17.so) ==19863== by 0x4008631: _dl_map_object (in /lib64/ld-2.17.so) ==19863== by 0x400C471: openaux (in /lib64/ld-2.17.so) ==19863== by 0x400E9C5: _dl_catch_error (in /lib64/ld-2.17.so) ==19863== by 0x400C6A2: _dl_map_object_deps (in /lib64/ld-2.17.so) ==19863== by 0x4003608: dl_main (in /lib64/ld-2.17.so) ==19863== by 0x4015307: _dl_sysdep_start (in /lib64/ld-2.17.so) ==19863== by 0x4004EC0: _dl_start (in /lib64/ld-2.17.so) ==19863== by 0x4001637: ??? (in /lib64/ld-2.17.so) ==19863== by 0x4: ??? ==19863== by 0xFFEFFE3D2: ??? ==19863== Address 0x626 is not stack'd, malloc'd or (recently) free'd ==19863== ==19863== ==19863== Process terminating with default action of signal 11 (SIGSEGV) ==19863== Bad permissions for mapped region at address 0x626 ==19863== at 0x626: ??? ==19863== by 0x400588C: open_verify (in /lib64/ld-2.17.so) ==19863== by 0x4008631: _dl_map_object (in /lib64/ld-2.17.so) ==19863== by 0x400C471: openaux (in /lib64/ld-2.17.so) ==19863== by 0x400E9C5: _dl_catch_error (in /lib64/ld-2.17.so) ==19863== by 0x400C6A2: _dl_map_object_deps (in /lib64/ld-2.17.so) ==19863== by 0x4003608: dl_main (in /lib64/ld-2.17.so) ==19863== by 0x4015307: _dl_sysdep_start (in /lib64/ld-2.17.so) ==19863== by 0x4004EC0: _dl_start (in /lib64/ld-2.17.so) ==19863== by 0x4001637: ??? (in /lib64/ld-2.17.so) ==19863== by 0x4: ??? ==19863== by 0xFFEFFE3D2: ??? ==19863== ==19863== HEAP SUMMARY: ==19863== in use at exit: 0 bytes in 0 blocks ==19863== total heap usage: 0 allocs, 0 frees, 0 bytes allocated ==19863== ==19863== All heap blocks were freed -- no leaks are possible ==19863== ==19863== For counts of detected and suppressed errors, rerun with: -v ==19863== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 2) ==19864== Memcheck, a memory error detector ==19864== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==19864== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info ==19864== Command: /usr/lib64/kde4/libexec/kioslave /usr/lib64/kde4/kio_sftp.so sftp local:/tmp/ksocket-mva/klauncherT20149.slave-socket local:/tmp/ksocket-mva/dolphinu20182.slave-socket ==19864== ==19866== Memcheck, a memory error detector ==19866== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==19866== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info ==19866== Command: /usr/lib64/kde4/libexec/kioslave /usr/lib64/kde4/kio_sftp.so sftp local:/tmp/ksocket-mva/klauncherT20149.slave-socket local:/tmp/ksocket-mva/dolphiny20182.slave-socket ==19866== ==19864== Conditional jump or move depends on uninitialised value(s) ==19864== at 0x11BF0BA0: ssh_options_set (in /usr/lib64/libssh.so.4.4.1) ==19864== by 0x119C44AF: ??? (in /usr/lib64/kde4/kio_sftp.so) ==19864== by 0x119C95CE: ??? (in /usr/lib64/kde4/kio_sftp.so) ==19864== by 0x119C1FED: ??? (in /usr/lib64/kde4/kio_sftp.so) ==19864== by 0x119C68D9: ??? (in /usr/lib64/kde4/kio_sftp.so) ==19864== by 0x4FF31B3: KIO::SlaveBase::dispatch(int, QByteArray const&) (in /usr/lib64/libkio.so.5.12.3) ==19864== by 0x4FEF585: KIO::SlaveBase::dispatchLoop() (in /usr/lib64/libkio.so.5.12.3) ==19864== by 0x119CD8BD: kdemain (in /usr/lib64/kde4/kio_sftp.so) ==19864== by 0x109200: ??? (in /usr/lib64/kde4/libexec/kioslave) ==19864== by 0x5B53C74: (below main) (in /lib64/libc-2.17.so) ==19864== ==19866== Conditional jump or move depends on uninitialised value(s) ==19866== at 0x11BF0BA0: ssh_options_set (in /usr/lib64/libssh.so.4.4.1) ==19866== by 0x119C44AF: ??? (in /usr/lib64/kde4/kio_sftp.so) ==19866== by 0x119C95CE: ??? (in /usr/lib64/kde4/kio_sftp.so) ==19866== by 0x119C1FED: ??? (in /usr/lib64/kde4/kio_sftp.so) ==19866== by 0x119C68D9: ??? (in /usr/lib64/kde4/kio_sftp.so) ==19866== by 0x4FF31B3: KIO::SlaveBase::dispatch(int, QByteArray const&) (in /usr/lib64/libkio.so.5.12.3) ==19866== by 0x4FEF585: KIO::SlaveBase::dispatchLoop() (in /usr/lib64/libkio.so.5.12.3) ==19866== by 0x119CD8BD: kdemain (in /usr/lib64/kde4/kio_sftp.so) ==19866== by 0x109200: ??? (in /usr/lib64/kde4/libexec/kioslave) ==19866== by 0x5B53C74: (below main) (in /lib64/libc-2.17.so) ==19866== (addition toprev comment: JavaScript warning: https://cdn.kde.org/js/modernizr.js, line 1: WebGL: Can't get a usable WebGL context ==19864== Mismatched free() / delete / delete [] ==19864== at 0x4C2B0CC: operator delete(void*) (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==19864== by 0x119C4A1E: ??? (in /usr/lib64/kde4/kio_sftp.so) ==19864== by 0x119CD8E5: kdemain (in /usr/lib64/kde4/kio_sftp.so) ==19864== by 0x109200: ??? (in /usr/lib64/kde4/libexec/kioslave) ==19864== by 0x5B53C74: (below main) (in /lib64/libc-2.17.so) ==19864== Address 0x1113e080 is 0 bytes inside a block of size 56 alloc'd ==19864== at 0x4C2C840: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==19864== by 0x119C4C55: ??? (in /usr/lib64/kde4/kio_sftp.so) ==19864== by 0x119CD87E: kdemain (in /usr/lib64/kde4/kio_sftp.so) ==19864== by 0x109200: ??? (in /usr/lib64/kde4/libexec/kioslave) ==19864== by 0x5B53C74: (below main) (in /lib64/libc-2.17.so) ==19864== ==19866== Mismatched free() / delete / delete [] ==19866== at 0x4C2B0CC: operator delete(void*) (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==19866== by 0x119C4A1E: ??? (in /usr/lib64/kde4/kio_sftp.so) ==19866== by 0x119CD8E5: kdemain (in /usr/lib64/kde4/kio_sftp.so) ==19866== by 0x109200: ??? (in /usr/lib64/kde4/libexec/kioslave) ==19866== by 0x5B53C74: (below main) (in /lib64/libc-2.17.so) ==19866== Address 0x1113e080 is 0 bytes inside a block of size 56 alloc'd ==19866== at 0x4C2C840: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==19866== by 0x119C4C55: ??? (in /usr/lib64/kde4/kio_sftp.so) ==19866== by 0x119CD87E: kdemain (in /usr/lib64/kde4/kio_sftp.so) ==19866== by 0x109200: ??? (in /usr/lib64/kde4/libexec/kioslave) ==19866== by 0x5B53C74: (below main) (in /lib64/libc-2.17.so) ==19866== ==19866== ==19866== HEAP SUMMARY: ==19866== in use at exit: 54,738 bytes in 470 blocks ==19866== total heap usage: 30,474 allocs, 30,004 frees, 27,906,187 bytes allocated ==19866== ==19866== LEAK SUMMARY: ==19866== definitely lost: 1,672 bytes in 2 blocks ==19866== indirectly lost: 4,022 bytes in 39 blocks ==19866== possibly lost: 4,676 bytes in 83 blocks ==19866== still reachable: 44,368 bytes in 346 blocks ==19866== suppressed: 0 bytes in 0 blocks ==19866== Rerun with --leak-check=full to see details of leaked memory ==19866== ==19866== For counts of detected and suppressed errors, rerun with: -v ==19866== Use --track-origins=yes to see where uninitialised values come from ==19866== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 2 from 2) ==19864== ==19864== HEAP SUMMARY: ==19864== in use at exit: 54,896 bytes in 468 blocks ==19864== total heap usage: 30,523 allocs, 30,055 frees, 27,908,083 bytes allocated ==19864== ==19864== LEAK SUMMARY: ==19864== definitely lost: 1,672 bytes in 2 blocks ==19864== indirectly lost: 4,022 bytes in 39 blocks ==19864== possibly lost: 4,676 bytes in 83 blocks ==19864== still reachable: 44,526 bytes in 344 blocks ==19864== suppressed: 0 bytes in 0 blocks ==19864== Rerun with --leak-check=full to see details of leaked memory ==19864== ==19864== For counts of detected and suppressed errors, rerun with: -v ==19864== Use --track-origins=yes to see where uninitialised values come from ==19864== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 2 from 2) Uhm... It seems, I found some heisenbug: I can't get kio_sftp to "not work" (like it is under "normally" started KDE), since it starts to work after I re-run kdeinit4 from userspace... Maybe I can try to add KDE_SLAVE_VALGRIND=sftp to session-start script?.. Uhm... I tried to add
> export KDE_SLAVE_VALGRIND=sftp
to /etc/X11/xinit/xinitrc and to /etc/X11/Sessions/KDE-4, but somewhy it has no effect, and it is no valgrind messages in ~/.xsession-errors :(
Where can I add it to make KDE apply it on session start (before it runs kdeinit4 itself)?
[sorry for flooding the bug] 1) I've found a way to enable debug on session start: I've added this export to the script in /etc/kde/startup/. 2) it is definitelly heisenbug: kio_sftp works either with 'export KDE_SLAVE_VALGRIND=sftp' in /etc/kde/startup or after manual restart kdeinit4 from userspace. But it does not work in usual circumstances... So, I definitely don't know how can I debug that problem :( Could you please install debuginfo packages for libssh and kderuntime so we get more information about this issue: ==19864== Conditional jump or move depends on uninitialised value(s) ==19864== at 0x11BF0BA0: ssh_options_set (in /usr/lib64/libssh.so.4.4.1) ==19864== by 0x119C44AF: ??? (in /usr/lib64/kde4/kio_sftp.so) ==19864== by 0x119C95CE: ??? (in /usr/lib64/kde4/kio_sftp.so) ==19864== by 0x119C1FED: ??? (in /usr/lib64/kde4/kio_sftp.so) ==19864== by 0x119C68D9: ??? (in /usr/lib64/kde4/kio_sftp.so) ==19864== by 0x4FF31B3: KIO::SlaveBase::dispatch(int, QByteArray const&) (in /usr/lib64/libkio.so.5.12.3) ==19864== by 0x4FEF585: KIO::SlaveBase::dispatchLoop() (in /usr/lib64/libkio.so.5.12.3) ==19864== by 0x119CD8BD: kdemain (in /usr/lib64/kde4/kio_sftp.so) ==19864== by 0x109200: ??? (in /usr/lib64/kde4/libexec/kioslave) ==19864== by 0x5B53C74: (below main) (in /lib64/libc-2.17.so) Created attachment 85724 [details]
valgrin.log
Here is some additional log info, but I still can't catch it's non-working state when it runs under valrgrind.
Created attachment 85725 [details]
additional valgrind log
And here is the log when connection to non-working sftp host (host, which doesn't provide ssh/sftp)
Great, debugsource should also be installed. So that valgrind can show the line number in the code where the issue is exactly. Which version of libssh are you using? (In reply to comment #12) > Great, debugsource should also be installed. So that valgrind can show the > line number in the code where the issue is exactly. actually, I not fully sure how can I motivate distromakers (Sabayon team) to provide additional source packages with sources placed in the right place (althought, Gentoo side of distro has an option for that, so I'll try). Also, will it be enough to just unpack the source tarballs to /usr/src/<cat>/<pkgname> as gentoo's "installsources" debug feature does, or there should be prepared (in some way) sources? And should the be placed somewhere exactly (maybe, builddir?) or it will be enough to just have it "somewhere"? ;) > Which version of libssh are you using? Installed versions: 0.6.3(23:01:39 17.03.2014)(sftp zlib debug -doc -examples -gcrypt -gssapi -pcap -server -ssh1 -static-libs) I will try to look into this too but I don't have time this week ... ping? Created attachment 89347 [details] Proposed patch Do you still experience this issue? If so, does the attached patch solve it? There's been a report on FreeBSD of a similar problem (https://mail.kde.org/pipermail/kde-freebsd/2014-October/018329.html). The "out of memory" part can be ignored, the error type was fixed earlier this year in http://marc.info/?l=kde-commits&m=138925976615991&w=2 Git commit 3dc39e92d34b3612e90f7a0b34d5d845a7af0b72 by Raphael Kubo da Costa. Committed on 30/10/2014 at 11:50. Pushed by rkcosta into branch 'KDE/4.14'. kio_sftp: Use the right type for timeout_sec and timeout_usec. libssh expects the values passed to the SSH_OPTIONS_TIMEOUT and SSH_OPTIONS_TIMEOUT_USEC to be longs, not plain ints. On 64-bit platforms with sizeof(long) > sizeof(int), this mismatch can be problematic and potentially result in invalid memory access that causes the calls to ssh_options_set() to fail. FIXED-IN: 4.14.3 REVIEW: 120900 M +1 -1 kioslave/sftp/kio_sftp.cpp http://commits.kde.org/kde-runtime/3dc39e92d34b3612e90f7a0b34d5d845a7af0b72 Git commit 3662f8beb435807a9ebc99ec722a877a5877b3fd by Raphael Kubo da Costa. Committed on 30/10/2014 at 12:33. Pushed by rkcosta into branch 'master'. kio_sftp: Use the right type for timeout_sec and timeout_usec. libssh expects the values passed to the SSH_OPTIONS_TIMEOUT and SSH_OPTIONS_TIMEOUT_USEC to be longs, not plain ints. On 64-bit platforms with sizeof(long) > sizeof(int), this mismatch can be problematic and potentially result in invalid memory access that causes the calls to ssh_options_set() to fail. Forward-ported from kde-runtime/3dc39e92d34b3612e90f7a0b34d5d845a7af0b72. REVIEW: 120900 M +1 -1 sftp/kio_sftp.cpp http://commits.kde.org/kio-extras/3662f8beb435807a9ebc99ec722a877a5877b3fd (In reply to Raphael Kubo da Costa from comment #16) > Created attachment 89347 [details] > Proposed patch > > Do you still experience this issue? If so, does the attached patch solve it? Yes, I'm still experience problem on 4.14.1. Will test patch now, thanks. Seems to be working. At least for now. Although, there was "lighty times" even when it was broken ;) P.S. will patch arrive in 4.14.3? Yes, as indicated in the "Version Fixed In" field at the top of the page :-) Hi. It seems, it is broken again in KF5. Although, in a bit another way: it is entirelly impossible to ask it to reconnect to the server, after it has been disconnected for whatever reason. Say, if I open some sftp host in dolphin, then wait some time (or restart server daemon, whatever), and then try to open some folder, or file — it will fail (after some long timeout). It will be only possible to open "cached" folders (that ones, that have been already opened in that dolphin instance). And only way to reconnect to server is to entirely close dolphin instance :( Vadim, please open a new but, this has nothing to do with this bug. |
Hi! I've found strange behaviour in kio_sftp (from 4.12.2): Somewhy, kio_sftp do not want to work with my kde profile (~/.kde4) and says: « Error. Out of memory. Could not set a timeout. » But (!!!). If I drop ~/.kde4/share/config/kdeglobals and relogin (!) — it works. At this moment ~/.kde4/share/config/kdeglobals contains only tho lines: >> [General] >> dbfile=/home/mva/.mozilla/firefox/<profile_name>/places.sqlite (btw, I absolutelly have no idea, why does it use Firefox's profile). And finally: when I change some setting (color, size) and relogin again — kio_sftp stops working again (and kdeglobals has all the settings it should, like colors and sizes) until I drop kdeglobals and relogin again. I tried to reproduce this bug with test system user with absolutely clean home directory and it was reproduced too. What additional info can I also provide? P.S. I'd be glad to fix that thing ASAP, since I really need SFTP functionality very much.