SLADE crashes frequently when replacing/adding/deleting files from other programs (directory)

[GeminiCrafterMan]

SLADE Version: 3.2.4 Operating System: Linux

Issue Details: This happens quite often when I do something like replace images in other programs, i.e. export some brightmaps from GIMP or edit some ZScript in VSCode. I don't do anything else, and I often accidentally leave SLADE open while doing this, since I had just aligned the sprites said brightmaps were based on, or am working on the code for the object that uses said sprites.

Stack Trace:

Version: 3.2.4
No current action

Operating System: Linux 6.6.3-arch1-1 x86_64
Graphics Vendor: AMD
Graphics Hardware: AMD Radeon Graphics (renoir, LLVM 16.0.6, DRM 3.54, 6.6.3-arch1-1)
OpenGL Version: 4.6 (Compatibility Profile) Mesa 23.2.1-arch1.2

Stack Trace:
0: [unknown location] [unknown:140653906039302]
1: [unknown location] [unknown:140653808640227]
2: [unknown location] [unknown:140653887866640]
3: [unknown location] [unknown:140653898022319]
4: [unknown location] [unknown:140653897085345]
5: [unknown location] g_closure_invoke
6: [unknown location] [unknown:140653902596662]
7: [unknown location] [unknown:140653902535234]
8: [unknown location] g_signal_emit_valist
9: [unknown location] g_signal_emit
10: [unknown location] wxGtkDataViewModelNotifier::ItemAdded(wxDataViewItem const&, wxDataViewItem const&)
11: [unknown location] wxDataViewModel::ItemAdded(wxDataViewItem const&, wxDataViewItem const&)
12: [unknown location] [unknown:93931718129159]
13: [unknown location] sigslot::signal_base<std::mutex, slade::Archive&, slade::ArchiveEntry&>::operator()(slade::Archive&, slade::ArchiveEntry&)
14: [unknown location] slade::Archive::addEntry(std::shared_ptr<slade::ArchiveEntry>, unsigned int, slade::ArchiveDir*)
15: [unknown location] slade::DirArchive::updateChangedEntries(std::vector<slade::DirEntryChange, std::allocator<slade::DirEntryChange> >&)
16: [unknown location] slade::DirArchiveUpdateDialog::onBtnOKClicked(wxCommandEvent&)
17: [unknown location] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&)
18: [unknown location] wxEvtHandler::SearchDynamicEventTable(wxEvent&)
19: [unknown location] wxEvtHandler::TryHereOnly(wxEvent&)
20: [unknown location] wxEvtHandler::ProcessEventLocally(wxEvent&)
21: [unknown location] wxEvtHandler::ProcessEvent(wxEvent&)
22: [unknown location] wxEvtHandler::SafelyProcessEvent(wxEvent&)
23: [unknown location] [unknown:140653914851944]
24: [unknown location] [unknown:140653902535539]
25: [unknown location] g_signal_emit_valist
26: [unknown location] g_signal_emit
27: [unknown location] [unknown:140653894603929]
28: [unknown location] g_closure_invoke
29: [unknown location] [unknown:140653902596986]
30: [unknown location] [unknown:140653902535234]
31: [unknown location] g_signal_emit_valist
32: [unknown location] g_signal_emit
33: [unknown location] [unknown:140653894603365]
34: [unknown location] [unknown:140653894330725]
35: [unknown location] [unknown:140653902535539]
36: [unknown location] g_signal_emit_valist
37: [unknown location] g_signal_emit
38: [unknown location] [unknown:140653895498247]
39: [unknown location] g_cclosure_marshal_VOID__BOXEDv
40: [unknown location] [unknown:140653902535539]
41: [unknown location] g_signal_emit_valist
42: [unknown location] g_signal_emit
43: [unknown location] [unknown:140653895474824]
44: [unknown location] [unknown:140653895504251]
45: [unknown location] [unknown:140653895506707]
46: [unknown location] gtk_event_controller_handle_event
47: [unknown location] [unknown:140653897210215]
48: [unknown location] [unknown:140653894353741]
49: [unknown location] g_closure_invoke
50: [unknown location] [unknown:140653902598378]
51: [unknown location] [unknown:140653902533429]
52: [unknown location] g_signal_emit_valist
53: [unknown location] g_signal_emit
54: [unknown location] [unknown:140653897271013]
55: [unknown location] [unknown:140653895805211]
56: [unknown location] gtk_main_do_event
57: [unknown location] [unknown:140653886802823]
58: [unknown location] [unknown:140653887163704]
59: [unknown location] [unknown:140653883662185]
60: [unknown location] [unknown:140653884048167]
61: [unknown location] g_main_loop_run
62: [unknown location] gtk_main
63: [unknown location] wxGUIEventLoop::DoRun()
64: [unknown location] wxEventLoopBase::Run()
65: [unknown location] wxDialog::ShowModal()
66: [unknown location] slade::ArchiveManagerPanel::onDirArchiveCheckCompleted(wxThreadEvent&)
67: [unknown location] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&)
68: [unknown location] wxEvtHandler::SearchDynamicEventTable(wxEvent&)
69: [unknown location] wxEvtHandler::TryHereOnly(wxEvent&)
70: [unknown location] wxEvtHandler::ProcessEventLocally(wxEvent&)
71: [unknown location] wxEvtHandler::ProcessEvent(wxEvent&)
72: [unknown location] wxEvtHandler::ProcessPendingEvents()
73: [unknown location] [unknown:140653904997932]
74: [unknown location] wxApp::DoIdle()
75: [unknown location] [unknown:140653914368744]
76: [unknown location] [unknown:140653883662185]
77: [unknown location] [unknown:140653884048167]
78: [unknown location] g_main_loop_run
79: [unknown location] gtk_main
80: [unknown location] wxGUIEventLoop::DoRun()
81: [unknown location] wxEventLoopBase::Run()
82: [unknown location] wxAppConsoleBase::MainLoop()
83: [unknown location] wxEntry(int&, wchar_t**)
84: [unknown location] main
85: [unknown location] [unknown:140653887773904]
86: [unknown location] __libc_start_main
87: [unknown location] _start

Last Log Messages:
Opening directory /home/dustinr/Desktop/Modding/Projects/Personal/gem-doomweps as archive
Opening took 218 ms
Setting up the OpenGL context
Initialising OpenGL...
OpenGL Version: 4.6
Max Texture Size: 16384x16384
Checking extensions...
Vertex Buffer Objects supported
Point Sprites supported
Framebuffer Objects supported

[GeminiCrafterMan]

As of 3.2.5, this now shows when that happens.

[sirjuddington]

Hmm did you build SLADE yourself? That kind of dialog should only show up in the debug build.

Helpful, though, think I might know what is happening - did you add a directory with files in it outside SLADE?

[GeminiCrafterMan]

No, adding a directory with files doesn't cause it every time... Usually, it's just one or two files in an existing directory, like a couple of new weapon sprites or a new ZScript file. And yes, I did build SLADE myself by installing it through yay.

[eevee]

I've also been having this happening, usually when adding and deleting files externally at the same time. Specifically, I've been porting some DECORATE to ZScript, and it seems to happen quite frequently when I (a) delete some file actors/foo.txt, (b) add a file zscript/foo.zs, and (c) modify the root DECORATE and ZSCRIPT to change the #includes over. But it's proving difficult to replicate.

I've seen both the above error:

/usr/src/debug/wxwidgets/wxWidgets/include/wx/dynarray.h(196): assert ""n != (-1)"" failed in Remove(): removing inexistent element in wxArray::Remove

As well as what seems to be the inverse:

/usr/src/debug/wxwidgets/wxWidgets/src/gtk/dataview.cpp(3979): assert ""parent_node"" failed in ItemAdded(): Did you forget a call to ItemAdded()? The parent node is unknown to the wxGtkTreeModel

And I think a secret third one, but I didn't manage to copy that.

---

So I tried to reproduce it reliably. I made a dummy directory containing some empty files:

- a
- b
- c/
  - d

Opened it in SLADE. Then I deleted c/d and touched c/e. SLADE noticed, picked it up, all fine.

I deleted c/e and touched c/d. SLADE noticed... that I deleted c/e, but not that c/d is back, and now it thinks c/ is empty. If I save the directory in SLADE, it now deletes c/d. So, uh, that's, probably not great.

(I've also noticed that SLADE likes to completely rewrite even files that it doesn't think have changed at all, which tends to make vim freak out and/or reload them all. And it deletes files it was never aware of, even if it doesn't think they were deleted within SLADE.)

I touched c/d again after saving, and now I'm back to where I started. Further messing around failed to produce a crash, although I did hit a couple more cases where an external change was just not noticed.

Very annoying! I'll start jotting down what changed before hitting OK on the dialog and maybe get some clues.