Bug 411528

Summary: KDevelop freezes for a long time on start when restoring a session
Product: [Applications] kdevelop Reporter: Adrián Chaves (Gallaecio) <adrian>
Component: generalAssignee: kdevelop-bugs-null
Status: REPORTED ---    
Severity: normal    
Priority: NOR    
Version First Reported In: 5.3.3   
Target Milestone: ---   
Platform: Other   
OS: Linux   
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:

Description Adrián Chaves (Gallaecio) 2019-09-02 15:23:51 UTC
When in a cryfs-mounted folder (Plasma Vault), importing an existing (Python) project folder into KDevelop works well.

However, after the initial import, starting a KDevelop session containing that project folder freezes KDevelop for a significant amount of time.

STEPS TO REPRODUCE
1. Follow the steps at https://github.com/cryfs/cryfs/issues/294 (including the post-exit workaround).
2. Reopen KDevelop

OBSERVED RESULT

KDevelop freezes upon start (if you switch to a different virtual desktop and back again, it’s window will still have the contents from the previous virtual desktop drawn on it) for a significant amount of time, which can increase to several minutes if additional Python packages are installed into the ‘venv’ folder.


EXPECTED RESULT

The KDevelop window does not freeze. KDevelop shows the same non-freezing behavior when importing a project (currently: no freeze) and when opening a session where that project has been already imported (currently: freeze).


SOFTWARE/OS VERSIONS

Operating System:  
KDE Plasma Version: 5.16.3
KDE Frameworks Version: 5.60.0
Qt Version: 5.12.4
Kernel Version: 4.19.26-1-CHAKRA
OS Type: 64-bit
Processors: 8 × AMD FX(tm)-8350 Eight-Core Processor
Memory: 15,6 GiB

ADDITIONAL INFORMATION

I wonder if this is may be related to Bug 408433.
Comment 1 Adrián Chaves (Gallaecio) 2019-09-21 07:39:04 UTC
As a workaround, I’m using Pipenv for Python projects in encrypted folders. Because Pipenv keeps virtual environment folders in a separate (not encrypted) location, the freeze time is much shorter.

This, however, means that Python dependencies are not encrypted. And while most come from the public PyPI repository, there are also dependencies installed from private Git repositories that should not be in an unencrypted folder.