https://bugs.kde.org/show_bug.cgi?id=387238
--- Comment #2 from RJVB <rjvber...@gmail.com> ---
1- I noticed the multiple reloads when I added a tracer to
AFMP::eventuallyReloadFolder(). It seems unavoidable that you'd get multiple
reloads when a background process causes frequent changes in a directory that's
being monitored for changes.
I observed this with the CodeBlocks source tree, a working copy off SVN which
had been configured for a standard in-tree build. Making a change to
configure.ac triggers an automatic process (autogen? autoconf + configure?) I'd
never noticed before and that I certainly didn't configure myself.
You may remember though that I made earlier mention of frequent reloading when
a project was being configured that I also had open in KDevelop.
I think this should be enough information to reproduce the issue.
FWIW here's a warning printed by your own 5.2.0 appimage build while loading
the same session:
inotify_add_watch("/path/to/codeblocks/work/trunk/conftest.dir") failed: "No
such file or directory"
That's a directory that was yanked out from under the project loader while it
was working because of that automatic autoconf whatever-it-is.
And when I quit the appimage build before it had gone idle I saw this:
/tmp/.mount_i2N9LD/AppRun: line 35: 13111 Segmentation fault (core dumped)
kdevelop $@
(no core was dumped, btw)
2- CPU profile. I can try to get one, but how do I get one that doesn't include
the initial load? Not sure how useful it'll be in diagnosing exactly what's
going on though. I've already seen quite a few hits in Qt regexp. functions
when I was interrupting the process earlier today.
3- I've also never really noticed it before. I just don't have that many large
projects that a) I build in-tree and b) I have open in KDevelop while doing so.
And even then: doing concurrent directory reloads is probably hardly ever a
problem other than an unnecessary waste of resources.
It can become a problem when reloads are triggered rapidly and for a
sufficiently long time (and without feedback to the user); the logical
explanation for the watchDir signals I received aimed at a stale watcher object
would be that the list job somehow continued after the project was unloaded.
--
You are receiving this mail because:
You are watching all bug changes.
