Clang build crashes
Closed this issue · 5 comments
Building with Clang works just fine, but the build crashes at startup with
(abaddon:81377): Gtk-CRITICAL **: 18:28:43.577: gtk_tree_model_sort_get_value: assertion 'VALID_ITER (iter, tree_model_sort)' failed
Running with debugger reveals that this occurs in ChannelListTree::SelectionFunc
when comparing type
abaddon/src/components/channellist/channellisttree.cpp
Lines 1154 to 1163 in 7b63bfe
I am not much familiar with GTK, but it seems like type
returned by get_iter
is in invalid state.
Clang version info:
> clang --version
clang version 16.0.6
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /nix/store/naz8m910ndn4s8w4wgkh8l8wxk2bcdnk-clang-16.0.6/bin
can you try this? idk why iter
would be invalid here but the tree model shit has always given me problems. let me know if selection breaks with this and ill look at some other options
diff --git a/src/components/channellist/channellisttree.cpp b/src/components/channellist/channellisttree.cpp
index 4816b42..35bfa2d 100644
--- a/src/components/channellist/channellisttree.cpp
+++ b/src/components/channellist/channellisttree.cpp
@@ -1158,8 +1158,11 @@ bool ChannelListTree::SelectionFunc(const Glib::RefPtr<Gtk::TreeModel> &model, c
}
}
- auto type = (*model->get_iter(path))[m_columns.m_type];
- return type == RenderType::TextChannel || type == RenderType::DM || type == RenderType::Thread;
+ if (const auto iter = model->get_iter(path)) {
+ auto type = (*iter)[m_columns.m_type];
+ return type == RenderType::TextChannel || type == RenderType::DM || type == RenderType::Thread;
+ }
+ return false;
}
void ChannelListTree::AddPrivateChannels() {
That fixed it, I don't see any problems with the channel selection. iter
might be invalid for some reason specifically on startup. I see that by default Abaddon selects the first channel in the list.
I had the same issue on OpenBSD with Clang version 13 since Abaddon version 0.1.14
I fixed this by compiling with -O1 instead of -O2.
Seems Clang's optimizations causes problems with this specific code block.
forgot about this but added the fix. realistically it was probably just UB