Built from tip of master (https://github.com/kduske/TrenchBroom/commit/61eed774ffea062d38457cc1e5ce013e41ff9159), Release configuration.
System is elementary 5.1.3, which is based on Ubuntu 18.04 LTS.
TB should not crash when changing a preference.
Open a map file, select a brush, activate the clip tool (through shortcut or button), and execute a 2-point or 3-point clip.
Then immediately open preferences and change the layout (# of panes). Crashes for me 100% reliably, tested with various Quake and Quake 3 map files.
Crash txt file indicates:
Reason: common/src/View/PickRequest.cpp:39: Condition 'm_camera != nullptr' failed: camera is null
OK finally got a chance to try to duplicate this on my main Manjaro Linux KDE desktop. I just built TrenchBroom-Linux-v2019.6-867-g61eed774f-RelWithDebInfo and followed what you do to recreate the crash, but I can't so far in the half dozen times I have tried. Building with RelWithDebInfo might be why it does not crash, not sure.
I do notice after closing the preferences window the [ESC] button no longer exits a selected tool or deselects a selected brush 100% of the time.
The ESC thing sounds like #3059 .
(pardon my "work persona", too lazy to switch accounts back to neogeographica)
One thing to add is that I only see the crash if changing prefs immediately after executing the clip. If for example I deactivate the clip tool then change prefs... no crash.
OK I have now gotten https://github.com/kduske/TrenchBroom/commit/61eed774ffea062d38457cc1e5ce013e41ff9159 to crash with some more info about it.
It only crashes for me going from one pane view to the multiple pane options or switching from any multiple pane options to other multiple pane options. It never crashes going from any of the multiple pane options to one pane. Doing that just triggers #3509, but no crash.
I only need to activate the clip tool, no need to plot out 2 or 3 clip points, or no need to execute a clip. The behavior is the same if you do those things or just activate the tool and go into preferences. As far as the timing going into the preferences I went into it immediately and other times after waiting as long as 30 seconds and my results are the same each time.
Did a bit of investigating. This and #3059 have the same underlying cause, the MapView2D/3D's created when we switch layouts are not fully initialized. Specifically:
In the normal "startup TB" case, these things are done by MapViewBase::documentDidChange.
Most helpful comment
Did a bit of investigating. This and #3059 have the same underlying cause, the MapView2D/3D's created when we switch layouts are not fully initialized. Specifically:
In the normal "startup TB" case, these things are done by MapViewBase::documentDidChange.