1. 30 Jan, 2023 1 commit
  2. 29 Jan, 2023 2 commits
  3. 28 Jan, 2023 2 commits
  4. 27 Jan, 2023 1 commit
  5. 26 Jan, 2023 1 commit
  6. 25 Jan, 2023 1 commit
  7. 24 Jan, 2023 15 commits
  8. 23 Jan, 2023 1 commit
  9. 22 Jan, 2023 4 commits
    • Igor Kushnir's avatar
      cmake: filter out generated and external CMake files earlier · 45aa4237
      Igor Kushnir authored
      Storing unneeded file paths and unnecessary CMake file classification
      wastes memory and CPU time.
      45aa4237
    • Igor Kushnir's avatar
      cmake: show a warning if project is configured with outdated data · 11010a3d
      Igor Kushnir authored
      When project data is outdated right after configuring, KDevelop does not
      reconfigure the project to avoid a reload loop in case of a bug or some
      upstream CMake change. Project data can be outdated right after
      configuring if the user edits a source CMake file during a CMake
      configure or generate step. In this case reloading the project will
      bring the data up to date. Show a warning that asks the user to do just
      that. The user can finish editing source CMake files, reload the
      project, and the reminding warning will disappear automatically. If a
      reload loop occurs for some reason, the user will eventually cease
      reloading and hopefully report a bug.
      
      I plan to implement the added TODO together with future project
      reloading fixes.
      
      CCBUG: 460450
      11010a3d
    • Igor Kushnir's avatar
      cmake: improve detection of outdated project data · 419d3a5d
      Igor Kushnir authored
      The current algorithm is simple: consider project data outdated if the
      API reply index file was last modified before a possibly generated
      source CMake file. Unfortunately this algorithm is unreliable:
      1) does not detect source CMake file modifications made during a CMake
         configure or generate step;
      2) ignores CMakeCache.txt modifications.
      
      Improvements in this commit:
      1. Consider project data invalid if KDevelop's CMake file API client
      query file does not exist. KDevelop never removes this file. The absence
      of the client query file can mean that it has never been created, in
      which case there can be no API reply; or it was removed during a prune
      job, which should have removed the API reply as well; or it was removed
      for some other reason, possibly an error.
      2. Consider project data outdated if the API reply index file was last
      modified before the API client query file. This means that a CMake
      generate step was canceled - probably because of some error.
      3. Consider project data outdated if the API reply index file was last
      modified before CMakeCache.txt. This can mean that the user modified
      CMakeCache.txt manually but did not run cmake afterwards, or run only a
      CMake configure step, but not a CMake generate step, which updates the
      API reply.
      4. Consider project data outdated if the API client query file was last
      modified before a non-generated source CMake file. A non-generated
      source CMake file can be last modified between the API client query and
      reply index files for two reasons:
        1) the user edited a source CMake file during a CMake configure or
           generate step, in which case project data is out of date;
        2) the user edited a source CMake file, then run CMake configure and
           generate steps outside of KDevelop, in which case project data is
           up to date.
      Since KDevelop cannot know the true reason, it should err on the side of
      caution and consider project data outdated in this case. The user is not
      supposed to edit generated CMake files, so ignoring their modifications
      is safe enough. Generated CMake files can be modified during a CMake
      configure step, which occurs after KDevelop creates the API client query
      file.
      5. Optimize by finishing CMake::FileApi::ImportJob as soon as it detects
      that project data is out of date, if
      ChooseCMakeInterfaceJob::tryDirectImport(), which discards outdated
      data, creates the job.
      
      Ignoring modifications to generated CMake files brings outdated project
      data detection algorithm closer to the algorithm in
      CMakeManager::integrateData(), which decides whether to reload a project
      when a file is changed. The remaining and just introduced
      inconsistencies between these two algorithms:
      1. Modifications to external source CMake files make project data
      outdated, but such modifications are not tracked. Watching each
      individual external CMake file can be costly and cause issues elsewhere
      if a watched item count limit is reached. QFileSystemWatcher's
      documentation warns:
        The act of monitoring files and directories for modifications consumes
        system resources. This implies there is a limit to the number of files
        and directories your process can monitor simultaneously.
      External source CMake files can be modified when the user updates an
      external dependency of a project opened in KDevelop, or when system
      updates are installed. The user should be aware of both events and can
      reload or reopen the project to reconfigure it, or restart KDevelop.
      2. Modifications to CMakeCache.txt make project data outdated, but such
      modifications are not tracked. Reloading the project after each
      CMakeCache.txt change is risky. CMakeCache.txt can be modified during a
      CMake configure step. If this CMake configure step occurs outside of
      KDevelop, concurrent CMake configuration runs can corrupt build data.
      Even if the CMake configure step that modifies CMakeCache.txt runs
      inside KDevelop, reloading the project risks creating a reload loop.
      
      When the user edits a source CMake file during a CMake configure or
      generate step, KDevelop prints a kdevelop.plugins.cmake.debug message:
      "the project is being reloaded, aborting reload!" but does not
      reconfigure the project automatically for now. But at least with this
      commit when KDevelop is restarted, it detects that project data is out
      of date and reconfigures the project.
      
      CCBUG: 460450
      419d3a5d
    • Script Kiddy's avatar
      GIT_SILENT Sync po/docbooks with svn · 518640f7
      Script Kiddy authored
      518640f7
  10. 21 Jan, 2023 9 commits
    • Igor Kushnir's avatar
      DebugController: connect to Sublime::MainWindow::areaChanged once · 6e42860b
      Igor Kushnir authored
      DebugController::areaChanged is connected to
      Sublime::MainWindow::areaChanged each time a debug session is started.
      These multiple connections result in repeated calls to
      m_currentSession->stopDebugger().
      
      Usually the first stopDebugger() call clears the command queue, sets
      s_shuttingDown debugger state on and queues a single command: GdbExit,
      which is then immediately executed. In this scenario the additional
      stopDebugger() calls have no effect, because they clear the already
      empty command queue, notice that the s_shuttingDown debugger state is on
      and return. However, if the current debug session was created by
      attaching to a process with GDB, the first stopDebugger() call queues
      two commands: TargetDetach and GdbExit. The TargetDetach command is
      executed, but the GdbExit command remains pending. The next (redundant)
      stopDebugger() call clears the command queue, that is removes/cancels
      the pending GdbExit command, and returns. The gdb process does not exit
      then. The fallback gdb-killing lambda, which runs after a 5-second
      timeout, finds that s_programExited debugger state is on and does
      nothing. As a result, the gdb process remains running, the debug session
      and the MIAttachProcessJob remain alive. Starting another debugging asks
      the user to abort the invisible currently running debug session. But the
      session is not actually aborted because it is stuck with an unexpected
      debugger state: s_programExited|s_attached|s_shuttingDown. In this way
      it is possible to create an unlimited number of gdb processes, debug
      sessions and MIAttachProcessJob objects, which are destroyed only on
      KDevelop exit.
      6e42860b
    • Igor Kushnir's avatar
      MIExamineCoreJob: don't leak the debug session if dialog is rejected · 031cfaff
      Igor Kushnir authored
      The constructor of a MI debug job creates a debug session. When the
      Select Core File dialog is rejected, MIExamineCoreJob doesn't call
      MIDebugSession::examineCoreFile() and finishes. The debug session is not
      destroyed and the Debug area remains active in KDevelop then.
      
      Calling MIDebugSession::stopDebugger() finishes the debug session and
      lets DebugController destroy it. This function explicitly and correctly
      handles stopping debugger when it is not started.
      031cfaff
    • Igor Kushnir's avatar
    • Igor Kushnir's avatar
      MIDebugJob: don't leak the debug session if config is invalid · a6183b28
      Igor Kushnir authored
      The constructor of a MI debug job creates a debug session. When the
      configured launch executable or its arguments are invalid, MIDebugJob
      doesn't call MIDebugSession::startDebugging() and finishes with an
      error. The debug session is not destroyed and the Debug area remains
      active in KDevelop then.
      
      Calling MIDebugSession::stopDebugger() finishes the debug session and
      lets DebugController destroy it. This function explicitly and correctly
      handles stopping debugger when it is not started.
      
      BUG: 369313
      FIXED-IN: 5.11.230400
      a6183b28
    • Igor Kushnir's avatar
      MIDebugJob: use unique named error codes instead of -1 · 73577df1
      Igor Kushnir authored
      The error codes help to classify error messages that appear in
      KDevelop's output. For example:
      kdevplatform.util: JOB ERROR: 331 "A shell meta character was included in the executable for the launch configuration 'test-project', this is not supported currently. Aborting start."
      73577df1
    • Igor Kushnir's avatar
      Extract MIDebugJob::finishWithError() · a72b1fe0
      Igor Kushnir authored
      a72b1fe0
    • Igor Kushnir's avatar
      Finish the debug session if debugging aborts on STTY error · 72c1dbc9
      Igor Kushnir authored
      When the external terminal emulator command is invalid, debugging an
      application fails to start with the error message "<invalid command> is
      incorrect terminal name". But then the debug session is not destroyed,
      commands in the command queue run and uselessly configure GDB, the Debug
      area remains active in KDevelop.
      72c1dbc9
    • Igor Kushnir's avatar
      debuggercommon: set STTY error message type to Error · 2f09d6ce
      Igor Kushnir authored
      User-requested debugging of an application fails to start in case of
      an STTY error, so the Information message type is not suitable.
      2f09d6ce
    • Script Kiddy's avatar
      GIT_SILENT Sync po/docbooks with svn · 4d9cbd81
      Script Kiddy authored
      4d9cbd81
  11. 20 Jan, 2023 3 commits
    • Igor Kushnir's avatar
      test_midbus: don't leak debug sessions · 2b68e11d
      Igor Kushnir authored
      DebugController is responsible for destroying debug sessions in
      KDevelop. Register test debug sessions with DebugController to properly
      clean them up.
      
      The following note is present in IDebugSession::breakpointController(),
      IDebugSession::variableController() and IDebugSession::frameStackModel()
      documentations:
        @note Implementations must ensure that a <(controller|model)> always
        exists (even if it is a dummy stub implementation that does nothing),
        and that it does not change during the lifetime of a session.
      DebugController::addSession() asserts that these functions return
      non-null pointers. Therefore TestDebugSession() creates these objects
      now. Pure virtual MIDebugSession::breakpointController() overrides
      IDebugSession::breakpointController() and returns
      MIBreakpointController, which inherits IBreakpointController.
      TestBreakpointController inherits IBreakpointController, not
      MIBreakpointController. Thus TestDebugSession has to create non-dummy
      MIBreakpointController rather than dummy TestBreakpointController.
      
      This commit is a proper debug session leak fix that replaces recently
      reverted fix in a wrong place 1256df11.
      2b68e11d
    • Igor Kushnir's avatar
      Don't leak the debug session if a debug job finishes in destructor · f051c8e3
      Igor Kushnir authored
      The constructor of a MI debug job creates a debug session. A debug
      session emits finished() and is destroyed when it finishes. A MI debug
      job finishes normally when its debug session emits finished(). When a MI
      debug job is killed, it calls MIDebugSession::stopDebugger(), which
      finishes the debug session. However, when a MI debug job is destroyed
      before it starts running, the debug session is leaked. A job should
      never leak resources, no matter when or how it is destroyed.
      
      If a MIDebugJob has a dependency, GdbLauncher::start() adds the
      MIDebugJob as the second subjob of an ExecuteCompositeJob. If an
      ExecuteCompositeJob is configured to abort on error (which is the
      default and almost always the case), when a subjob finishes with an
      error, the remaining subjobs are never started, the composite job
      finishes and is soon destroyed. The remaining subjobs are owned by the
      composite job and are destroyed along with it. This scenario happens
      when a MIDebugJob job depends on a build job, and the build job fails,
      e.g. because of a syntax error in the program. Without this commit, the
      job's debug session is not destroyed and the Debug area remains active
      in KDevelop then.
      
      ExecuteCompositeJob::doKill() does not kill the remaining subjobs if
      killing a subjob fails. Since ExecuteCompositeJob is a parent of its
      subjobs, the not-killed subjobs are eventually destroyed along with it.
      Furthermore, I believe that not-started subjobs should always be simply
      destroyed rather than killed, and plan to implement this change soon.
      
      BUG: 394104
      FIXED-IN: 5.11.230400
      f051c8e3
    • Igor Kushnir's avatar
      debuggercommon: expand debug job and session debug output · 10b277fb
      Igor Kushnir authored
      The expanded output helps to understand debug job and debug session
      lifetime patterns.
      10b277fb