https://bugs.kde.org/show_bug.cgi?id=495261
--- Comment #12 from Igor Kushnir <igor...@gmail.com> --- (In reply to Matthew Woehlke from comment #8) > > Maybe a small program ... > > Alas, I don't think it's going to be that simple. I tried this: A good sample program. I just tested it in Debug and Release and it never crashed. Added debug output and verified that getMTime() is never called in the main thread. Looked at recent Qt commits that touched related code. Found a major reimplementation https://codereview.qt-project.org/c/qt/qtbase/+/495840 (first released in Qt 6.7.0) and a fix https://codereview.qt-project.org/c/qt/qtbase/+/578874 (not released yet, only in the dev branch). The second commit looks like it could fix the crash of the first backtrace, but likely not the second backtrace. Could be a regression in Qt 6.7.0 caused by the major reimplementation. Alas KDevelop 6.0 was released after Qt 6.7.0, so few people have tested it with earlier Qt versions. Found this possibly related comment https://bugreports.qt.io/browse/QTBUG-73271?focusedId=444540&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-444540 : "Apparently tzset(3) cannot be called concurrently in a safe way." Qt locks a mutex before calling tzset() as can be seen here: https://codebrowser.dev/qt6/qtbase/src/corelib/global/qtenvironmentvariables.cpp.html#_Z10qLocalTimelP2tm . A comment in the same file says "Access to the tzname[] global in one thread is UB if any other is calling tzset() or anything that behaves as if it called tzset(). So also lock this access to prevent such collisions." Maybe KDevelop uses some non-Qt API concurrently, which cannot possibly lock the same mutex, and that causes a data race and this crash? -- You are receiving this mail because: You are watching all bug changes.
