| Summary: | Crash when debugging a launch and a working set from another area has not been visited | ||
|---|---|---|---|
| Product: | [Applications] kdevelop | Reporter: | David E. Narvaez <david.narvaez> |
| Component: | general | Assignee: | kdevelop-bugs-null |
| Status: | RESOLVED FIXED | ||
| Severity: | crash | CC: | niko.sams |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | 4.2.3 | ||
| Platform: | Compiled Sources | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
David E. Narvaez
2012-01-07 05:26:05 UTC
does this happen only when starting debugging or also when switching manually to debug area? (In reply to comment #1) > does this happen only when starting debugging or also when switching manually > to debug area? Switching man ually to the debug area does not result in a crash. It seems to happen only when KDevelop "automatically" changes to a new area, for whatever that means codewise (see my next comment for another example). Another way to reproduce is: 1. Get two working sets in a versioned project 2. Open one working set in the Review area 3. Open the other working set in the Code area 4. Close KDevelop (while on the Code area) 5. Open KDevelop again 6. Right click on the project and show differences 7. KDevelop crashes in assertion Q_ASSERT(textDoc) while changing to Review area (In reply to comment #2) > (In reply to comment #1) > > does this happen only when starting debugging or also when switching manually > > to debug area? > > Switching man ually to the debug area does not result in a crash. It seems to > happen only when KDevelop "automatically" changes to a new area, for whatever > that means codewise (see my next comment for another example). Just checked the code and, for the record, the difference between manually and automatically is void MainWindowPrivate::toggleArea ( int index ) and void UiController::switchToArea(const QString &areaName, SwitchMode switchMode) Hmm, did you try this recently? documentLoaded protects against doc->textDocument() being null and returns instead of calling adaptEditorIndentationMode (thats where the assert happens according to you BT). So I don't see how the Q_ASSERT can happen, except if somehow something deletes the textdocument of the specific document while the call is made. But that would mean there's got to be a race and it should be reproducable only part of the time. I can't reproduce this any more, so I'm marking this as fixed. Thanks! |