https://bugs.kde.org/show_bug.cgi?id=495261
--- Comment #7 from Igor Kushnir <igor...@gmail.com> --- (In reply to Matthew Woehlke from comment #6) > > Could you print the value of the local variable `localFile` at crash time? > > Which stack frame? The QFileInfo (#16) seems to be > `Tests/RunCMake/Graphviz/set_graph_name-check.cmake`... except I ran the > test again and got `Tests/Environment/check_mod.cmake`. It isn't consistent. > (Times I've just observed the file name from the parsing status, it also > seems to always be on a `.cmake` file when it dies. This *does* make me > suspect that the issue is related to parsing CMake, not C++. I'd be shocked > if CMake itself doesn't have significantly more CMake-language files in the > tree than just about anything else, which would explain why feeding KDevelop > the CMake sources specifically is most likely to cause the crash.) > > That said, you'll note the above backtrace is different, and appears to be > looking at `Source/cmXCOFF.h` (although I had to go up to #26 to get this), > so... 🤷 The previous runs seemed to have the same trace as above. Anyway, > if it's some sort of race, trying to get a reduced test case is probably not > going to go well. I concede that this looks very much like a thread safety bug. Maybe a small program that repeatedly runs code like the following in *many* threads concurrently would reproduce the bug? ``` QString localFile("/path/to/a/file"); QFileInfo fileInfo(localFile); QDateTime lastModified = fileInfo.lastModified(); qCritical() << lastModified; // prevent compiler's optimizing away ``` > > Can you try to call `tzset()` once from the main thread somewhere, e.g. > > main? > > How would I do that? Would I need a from-source build of KDevelop? Either that or patch your system KDevelop version. Would be unnecessary if you manage to create a small example that reproduces the Qt bug. You could run `tzset()` once from the main thread of the example program then. -- You are receiving this mail because: You are watching all bug changes.