Segmentation fault on creating wxRadioButton

[utelle]

I try to compile and test a wx application under wxGTK 3.1.7, GCC 9.4.0, Ubuntu 20.04. GTK version 3.24.20. However, I experience a segmentation fault during creating the controls for the main frame of the application.

The segmentation fault happens on creating a wxRadioButton object, when GetBestSize is called in the PostCreation code. Following is the call stack:

libc.so.6!__memmove_avx_unaligned_erms() (/build/glibc-SzIz7B/glibc-2.31/sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:240)
libpng16.so.16![Unknown/Just-In-Time compiled code] (Unbekannte Quelle:0)
libpng16.so.16!png_process_data (Unbekannte Quelle:0)
libpixbufloader-png.so![Unknown/Just-In-Time compiled code] (Unbekannte Quelle:0)
libgdk_pixbuf-2.0.so.0!gdk_pixbuf_loader_close (Unbekannte Quelle:0)
libgdk_pixbuf-2.0.so.0![Unknown/Just-In-Time compiled code] (Unbekannte Quelle:0)
libgdk_pixbuf-2.0.so.0!gdk_pixbuf_new_from_stream (Unbekannte Quelle:0)
libgdk_pixbuf-2.0.so.0!gdk_pixbuf_new_from_resource (Unbekannte Quelle:0)
libgtk-3.so.0![Unknown/Just-In-Time compiled code] (Unbekannte Quelle:0)
libgtk-3.so.0!gtk_widget_get_preferred_height_and_baseline_for_width (Unbekannte Quelle:0)
libgtk-3.so.0![Unknown/Just-In-Time compiled code] (Unbekannte Quelle:0)
libwx_gtk3u_core-3.1.so.7!wxControl::GTKGetPreferredSize(const wxControl * const this, GtkWidget * widget) (/home/ulrich/Development/GitHub/wxWidgets/src/gtk/control.cpp:354)
libwx_gtk3u_core-3.1.so.7!wxControl::DoGetBestSize(const wxControl * const this) (/home/ulrich/Development/GitHub/wxWidgets/src/gtk/control.cpp:89)
libwx_gtk3u_core-3.1.so.7!wxWindowBase::GetBestSize(const wxWindowBase * const this) (/home/ulrich/Development/GitHub/wxWidgets/src/common/wincmn.cpp:913)
libwx_gtk3u_core-3.1.so.7!wxWindowBase::GetEffectiveMinSize(const wxWindowBase * const this) (/home/ulrich/Development/GitHub/wxWidgets/src/common/wincmn.cpp:894)
libwx_gtk3u_core-3.1.so.7!wxWindowBase::SetInitialSize(wxWindowBase * const this, const wxSize & size) (/home/ulrich/Development/GitHub/wxWidgets/src/common/wincmn.cpp:967)
libwx_gtk3u_core-3.1.so.7!wxControl::PostCreation(wxControl * const this, const wxSize & size) (/home/ulrich/Development/GitHub/wxWidgets/src/gtk/control.cpp:113)
libwx_gtk3u_core-3.1.so.7!wxRadioButton::Create(wxRadioButton * const this, wxWindow * parent, wxWindowID id, const wxString & label, const wxPoint & pos, const wxSize & size, long style, const wxValidator & validator, const wxString & name) (/home/ulrich/Development/GitHub/wxWidgets/src/gtk/radiobut.cpp:105)
wxRadioButton::wxRadioButton(wxRadioButton * const this, wxWindow * parent, wxWindowID id, const wxString & label, const wxPoint & pos, const wxSize & size, long style, const wxValidator & validator, const wxString & name) (/usr/local/include/wx-3.1/wx/gtk/radiobut.h:29)
c2prog::ui::C2ProgMainFrame::CreateControls(c2prog::ui::C2ProgMainFrame * const this) (/home/ulrich/Development/wxgui-testing/src/c2prog/wx/c2progmain.cpp:205)

Any idea, what's going on? I would be grateful for any hints helping me to solve the problem.

BTW, the very same application runs flawlessly under Windows.

Regards,

Ulrich

[Vadim Zeitlin]

On Tue, 21 Jun 2022 14:52:52 -0700 (PDT) utelle wrote:

u> I try to compile and test a wx application under wxGTK 3.1.7, GCC 9.4.0,
u> Ubuntu 20.04. GTK version 3.24.20. However, I experience a segmentation
u> fault during creating the controls for the main frame of the application.

FWIW I haven't had any such problems under Ubuntu 20.04, but, after
checking my chroot, it was with gcc 9.3. But I don't see at all how could a
change in the minor version of the compiler result in anything like this.

u> The segmentation fault happens on creating a wxRadioButton object, when
u> GetBestSize is called in the PostCreation code.

Does this happen in the widgets sample, which uses radio buttons? And/or
in the minimal sample if you add a radio button to it?

u> Following is the call stack:
u>
u> libc.so.6!__memmove_avx_unaligned_erms()
u> (/build/glibc-SzIz7B/glibc-2.31/sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:240)
u> libpng16.so.16![Unknown/Just-In-Time compiled code] (Unbekannte Quelle:0)
u> libpng16.so.16!png_process_data (Unbekannte Quelle:0)
u> libpixbufloader-png.so![Unknown/Just-In-Time compiled code] (Unbekannte
u> Quelle:0)
u> libgdk_pixbuf-2.0.so.0!gdk_pixbuf_loader_close (Unbekannte Quelle:0)
u> libgdk_pixbuf-2.0.so.0![Unknown/Just-In-Time compiled code] (Unbekannte
u> Quelle:0)
u> libgdk_pixbuf-2.0.so.0!gdk_pixbuf_new_from_stream (Unbekannte Quelle:0)
u> libgdk_pixbuf-2.0.so.0!gdk_pixbuf_new_from_resource (Unbekannte Quelle:0)
u> libgtk-3.so.0![Unknown/Just-In-Time compiled code] (Unbekannte Quelle:0)
u> libgtk-3.so.0!gtk_widget_get_preferred_height_and_baseline_for_width
u> (Unbekannte Quelle:0)

It would be useful to install the corresponding dbgsym packages to get
something other than "unknown source" here. But it almost looks like it's
using incompatible libpng versions. How did you configure wx and which
libpng did it pick?

Regards,
VZ

--
TT-Solutions: wxWidgets consultancy and technical support
http://www.tt-solutions.com/

[utelle]

Vadim Zeitlin schrieb am Mittwoch, 22. Juni 2022 um 00:19:34 UTC+2:

On Tue, 21 Jun 2022 14:52:52 -0700 (PDT) utelle wrote:

u> I try to compile and test a wx application under wxGTK 3.1.7, GCC 9.4.0,
u> Ubuntu 20.04. GTK version 3.24.20. However, I experience a segmentation
u> fault during creating the controls for the main frame of the application.

FWIW I haven't had any such problems under Ubuntu 20.04, but, after
checking my chroot, it was with gcc 9.3. But I don't see at all how could a
change in the minor version of the compiler result in anything like this.

Most likely I have made some installation mistakes. For a certain project I needed to use Visual Studio Code and CMake. I had to build CMake myself, because the version installed via snap did not work from within VS Code for whatever reason - I get the message "need to run as root or suid", although it can be run from a terminal without problems.

 

u> The segmentation fault happens on creating a wxRadioButton object, when
u> GetBestSize is called in the PostCreation code.

Does this happen in the widgets sample, which uses radio buttons? And/or
in the minimal sample if you add a radio button to it?

I have to test that.

 

u> (Unbekannte Quelle:0)

It would be useful to install the corresponding dbgsym packages to get
something other than "unknown source" here. But it almost looks like it's
using incompatible libpng versions. How did you configure wx and which
libpng did it pick? 

I used

../configure --with-gtk --enable-debug

The system libpng is used. Version is 1.6.37-2.

Regards,

Ulrich

[Vadim Zeitlin]

On Tue, 21 Jun 2022 16:11:22 -0700 (PDT) utelle wrote:

u> I used
u>
u> ../configure --with-gtk --enable-debug
u>
u> The system libpng is used. Version is 1.6.37-2.

If wx built-in libpng is not used, I have absolutely no idea what could
explain this crash, sorry.

Please let us know if you find anything more or can reproduce it in a
self-contained example.

Thanks and good luck!

[utelle]

Vadim Zeitlin schrieb am Mittwoch, 22. Juni 2022 um 01:31:47 UTC+2:

On Tue, 21 Jun 2022 16:11:22 -0700 (PDT) utelle wrote:

u> I used
u>
u> ../configure --with-gtk --enable-debug
u>
u> The system libpng is used. Version is 1.6.37-2.

If wx built-in libpng is not used, I have absolutely no idea what could
explain this crash, sorry.

Please let us know if you find anything more or can reproduce it in a
self-contained example.

Well, I started again from scratch with a clean Ubuntu VM. I did a fresh build of wxWidgets 3.1.7. I tested the "dialogs" sample coming with wxWidgets as a Makefile project from Visual Studio Code. That worked flawlessly. Then I built my own project as a CMake project from Visual Studio Code. The build succeeded, but after starting the application in debug mode it crashed at the very same place. Here is the callstack again:

libc.so.6!__memmove_avx_unaligned_erms() (/build/glibc-SzIz7B/glibc-2.31/sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:240)
libpng16.so.16![Unknown/Just-In-Time compiled code] (Unknown Source:0)
libpng16.so.16!png_process_data (Unknown Source:0)
libpixbufloader-png.so![Unknown/Just-In-Time compiled code] (Unknown Source:0)
libgdk_pixbuf-2.0.so.0!gdk_pixbuf_loader_close (Unknown Source:0)
libgdk_pixbuf-2.0.so.0![Unknown/Just-In-Time compiled code] (Unknown Source:0)
libgdk_pixbuf-2.0.so.0!gdk_pixbuf_new_from_stream (Unknown Source:0)
libgdk_pixbuf-2.0.so.0!gdk_pixbuf_new_from_resource (Unknown Source:0)
libgtk-3.so.0![Unknown/Just-In-Time compiled code] (Unknown Source:0)
libgtk-3.so.0!gtk_widget_get_preferred_height_and_baseline_for_width (Unknown Source:0)
libgtk-3.so.0![Unknown/Just-In-Time compiled code] (Unknown Source:0)
libwx_gtk3u_core-3.1.so.7!wxControl::GTKGetPreferredSize(const wxControl * const this, GtkWidget * widget) (/home/ulrich/Development/wxWidgets/3.1.7/src/gtk/control.cpp:354)
libwx_gtk3u_core-3.1.so.7!wxControl::DoGetBestSize(const wxControl * const this) (/home/ulrich/Development/wxWidgets/3.1.7/src/gtk/control.cpp:89)
libwx_gtk3u_core-3.1.so.7!wxWindowBase::GetBestSize(const wxWindowBase * const this) (/home/ulrich/Development/wxWidgets/3.1.7/src/common/wincmn.cpp:913)
libwx_gtk3u_core-3.1.so.7!wxWindowBase::GetEffectiveMinSize(const wxWindowBase * const this) (/home/ulrich/Development/wxWidgets/3.1.7/src/common/wincmn.cpp:894)
libwx_gtk3u_core-3.1.so.7!wxWindowBase::SetInitialSize(wxWindowBase * const this, const wxSize & size) (/home/ulrich/Development/wxWidgets/3.1.7/src/common/wincmn.cpp:967)
libwx_gtk3u_core-3.1.so.7!wxControl::PostCreation(wxControl * const this, const wxSize & size) (/home/ulrich/Development/wxWidgets/3.1.7/src/gtk/control.cpp:113)
libwx_gtk3u_core-3.1.so.7!wxRadioButton::Create(wxRadioButton * const this, wxWindow * parent, wxWindowID id, const wxString & label, const wxPoint & pos, const wxSize & size, long style, const wxValidator & validator, const wxString & name) (/home/ulrich/Development/wxWidgets/3.1.7/src/gtk/radiobut.cpp:105)
wxRadioButton::wxRadioButton(wxRadioButton * const this, wxWindow * parent, wxWindowID id, const wxString & label, const wxPoint & pos, const wxSize & size, long style, const wxValidator & validator, const wxString & name) (/home/ulrich/opt/wxWidgets/3-1-7/include/wx-3.1/wx/gtk/radiobut.h:29)
c2prog::ui::C2ProgMainFrame::CreateControls(c2prog::ui::C2ProgMainFrame * const this) (/home/ulrich/Development/CodeSkin/wxgui-testing/src/c2prog/wx/c2progmain.cpp:205)
c2prog::ui::C2ProgMainFrame::Create(c2prog::ui::C2ProgMainFrame * const this, wxWindow * parent, wxWindowID id, const wxString & caption, const wxPoint & pos, const wxSize & size, long style) (/home/ulrich/Development/CodeSkin/wxgui-testing/src/c2prog/wx/c2progmain.cpp:89)
c2prog::ui::C2ProgMainFrame::C2ProgMainFrame(c2prog::ui::C2ProgMainFrame * const this, wxWindow * parent, wxWindowID id, const wxString & caption, const wxPoint & pos, const wxSize & size, long style) (/home/ulrich/Development/CodeSkin/wxgui-testing/src/c2prog/wx/c2progmain.cpp:81)
C2ProgApp::OnInit(C2ProgApp * const this) (/home/ulrich/Development/CodeSkin/wxgui-testing/src/c2prog/wx/c2progapp.cpp:177)
wxAppConsoleBase::CallOnInit(wxAppConsoleBase * const this) (/home/ulrich/opt/wxWidgets/3-1-7/include/wx-3.1/wx/app.h:93)
libwx_baseu-3.1.so.7!wxEntry(int & argc, wxChar ** argv) (/home/ulrich/Development/wxWidgets/3.1.7/src/common/init.cpp:487)
libwx_baseu-3.1.so.7!wxEntry(int & argc, char ** argv) (/home/ulrich/Development/wxWidgets/3.1.7/src/common/init.cpp:515)
main(int argc, char ** argv) (/home/ulrich/Development/wxgui-testing/src/c2prog/wx/c2progapp.cpp:47)

I'm really at a loss, how to proceed to find the cause of the problem.

In a previous post you wrote:

> It would be useful to install the corresponding dbgsym packages to get
something other than "unknown source" here.

How do I install dbgsym packages? Sorry for the dumb question, but I have only limited experience with Linux systems.

Regards,

Ulrich

[utelle]

I temporarily removed the radio buttons from the dialog. However, this didn't solve the problem. I experienced a crash again on trying to show a modal dialog. Here is the callstack:

libc.so.6!__memmove_avx_unaligned_erms() (/build/glibc-SzIz7B/glibc-2.31/sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:240)

libpng16.so.16![Unknown/Just-In-Time compiled code] (Unknown Source:0)
libpng16.so.16!png_process_data (Unknown Source:0)
libpixbufloader-png.so![Unknown/Just-In-Time compiled code] (Unknown Source:0)
libgdk_pixbuf-2.0.so.0!gdk_pixbuf_loader_close (Unknown Source:0)
libgdk_pixbuf-2.0.so.0![Unknown/Just-In-Time compiled code] (Unknown Source:0)
libgdk_pixbuf-2.0.so.0!gdk_pixbuf_new_from_stream (Unknown Source:0)
libgdk_pixbuf-2.0.so.0!gdk_pixbuf_new_from_resource (Unknown Source:0)
libgtk-3.so.0![Unknown/Just-In-Time compiled code] (Unknown Source:0)

libgobject-2.0.so.0!g_closure_invoke (Unknown Source:0)
libgobject-2.0.so.0![Unknown/Just-In-Time compiled code] (Unknown Source:0)
libgobject-2.0.so.0!g_signal_emit_valist (Unknown Source:0)
libgobject-2.0.so.0!g_signal_emit (Unknown Source:0)
libgtk-3.so.0!gtk_widget_show (Unknown Source:0)
libwx_gtk3u_core-3.1.so.7!wxWindow::Show(wxWindow * const this, bool show) (/home/ulrich/Development/wxWidgets/3.1.7/src/gtk/window.cpp:4334)
libwx_gtk3u_core-3.1.so.7!wxTopLevelWindowGTK::Show(wxTopLevelWindowGTK * const this, bool show) (/home/ulrich/Development/wxWidgets/3.1.7/src/gtk/toplevel.cpp:1169)
libwx_gtk3u_core-3.1.so.7!wxDialog::Show(wxDialog * const this, bool show) (/home/ulrich/Development/wxWidgets/3.1.7/src/gtk/dialog.cpp:71)
libwx_gtk3u_core-3.1.so.7!wxDialog::ShowModal(wxDialog * const this) (/home/ulrich/Development/wxWidgets/3.1.7/src/gtk/dialog.cpp:163)
c2prog::ui::C2ProgMainFrame::OnUpdateCheckClick(c2prog::ui::C2ProgMainFrame * const this, wxCommandEvent & event) (/home/ulrich/Development/CodeSkin/wxgui-testing/src/c2prog/wx/c2progmain.cpp:471)
libwx_baseu-3.1.so.7!wxAppConsoleBase::HandleEvent(const wxAppConsoleBase * const this, wxEvtHandler * handler, wxEventFunction func, wxEvent & event) (/home/ulrich/Development/wxWidgets/3.1.7/src/common/appbase.cpp:654)
libwx_baseu-3.1.so.7!wxAppConsoleBase::CallEventHandler(const wxAppConsoleBase * const this, wxEvtHandler * handler, wxEventFunctor & functor, wxEvent & event) (/home/ulrich/Development/wxWidgets/3.1.7/src/common/appbase.cpp:666)
libwx_baseu-3.1.so.7!wxEvtHandler::ProcessEventIfMatchesId(const wxEventTableEntryBase & entry, wxEvtHandler * handler, wxEvent & event) (/home/ulrich/Development/wxWidgets/3.1.7/src/common/event.cpp:1431)
libwx_baseu-3.1.so.7!wxEventHashTable::HandleEvent(wxEventHashTable * const this, wxEvent & event, wxEvtHandler * self) (/home/ulrich/Development/wxWidgets/3.1.7/src/common/event.cpp:1039)
libwx_baseu-3.1.so.7!wxEvtHandler::TryHereOnly(wxEvtHandler * const this, wxEvent & event) (/home/ulrich/Development/wxWidgets/3.1.7/src/common/event.cpp:1628)
libwx_baseu-3.1.so.7!wxEvtHandler::TryBeforeAndHere(wxEvtHandler * const this, wxEvent & event) (/home/ulrich/Development/wxWidgets/3.1.7/include/wx/event.h:4007)
libwx_baseu-3.1.so.7!wxEvtHandler::ProcessEventLocally(wxEvtHandler * const this, wxEvent & event) (/home/ulrich/Development/wxWidgets/3.1.7/src/common/event.cpp:1561)
libwx_baseu-3.1.so.7!wxEvtHandler::ProcessEvent(wxEvtHandler * const this, wxEvent & event) (/home/ulrich/Development/wxWidgets/3.1.7/src/common/event.cpp:1534)
libwx_baseu-3.1.so.7!wxEvtHandler::ProcessPendingEvents(wxEvtHandler * const this) (/home/ulrich/Development/wxWidgets/3.1.7/src/common/event.cpp:1398)
libwx_baseu-3.1.so.7!wxAppConsoleBase::ProcessPendingEvents(wxAppConsoleBase * const this) (/home/ulrich/Development/wxWidgets/3.1.7/src/common/appbase.cpp:563)
libwx_gtk3u_core-3.1.so.7!wxApp::DoIdle(wxApp * const this) (/home/ulrich/Development/wxWidgets/3.1.7/src/gtk/app.cpp:151)
libwx_gtk3u_core-3.1.so.7!wxapp_idle_callback() (/home/ulrich/Development/wxWidgets/3.1.7/src/gtk/app.cpp:101)
libglib-2.0.so.0!g_main_context_dispatch (Unknown Source:0)
libglib-2.0.so.0![Unknown/Just-In-Time compiled code] (Unknown Source:0)
libglib-2.0.so.0!g_main_loop_run (Unknown Source:0)
libgtk-3.so.0!gtk_dialog_run (Unknown Source:0)
libwx_gtk3u_core-3.1.so.7!wxMessageDialog::ShowModal(wxMessageDialog * const this) (/home/ulrich/Development/wxWidgets/3.1.7/src/gtk/msgdlg.cpp:272)
libwx_gtk3u_core-3.1.so.7!wxMessageBox(const wxString & message, const wxString & caption, long style, wxWindow * parent) (/home/ulrich/Development/wxWidgets/3.1.7/src/common/utilscmn.cpp:1365)
libwx_gtk3u_core-3.1.so.7!wxLogGui::DoShowSingleLogMessage(wxLogGui * const this, const wxString & message, const wxString & title, int style) (/home/ulrich/Development/wxWidgets/3.1.7/src/generic/logg.cpp:244)
libwx_gtk3u_core-3.1.so.7!wxLogGui::Flush(wxLogGui * const this) (/home/ulrich/Development/wxWidgets/3.1.7/src/generic/logg.cpp:315)
libwx_baseu-3.1.so.7!wxLog::FlushActive() (/home/ulrich/Development/wxWidgets/3.1.7/src/common/log.cpp:840)
libwx_baseu-3.1.so.7!wxAppConsoleBase::ProcessIdle(wxAppConsoleBase * const this) (/home/ulrich/Development/wxWidgets/3.1.7/src/common/appbase.cpp:436)
libwx_gtk3u_core-3.1.so.7!wxAppBase::ProcessIdle(wxAppBase * const this) (/home/ulrich/Development/wxWidgets/3.1.7/src/common/appcmn.cpp:396)
libwx_gtk3u_core-3.1.so.7!wxApp::DoIdle(wxApp * const this) (/home/ulrich/Development/wxWidgets/3.1.7/src/gtk/app.cpp:153)
libwx_gtk3u_core-3.1.so.7!wxapp_idle_callback() (/home/ulrich/Development/wxWidgets/3.1.7/src/gtk/app.cpp:101)
libglib-2.0.so.0!g_main_context_dispatch (Unknown Source:0)
libglib-2.0.so.0![Unknown/Just-In-Time compiled code] (Unknown Source:0)
libglib-2.0.so.0!g_main_loop_run (Unknown Source:0)
libgtk-3.so.0!gtk_main (Unknown Source:0)
libwx_gtk3u_core-3.1.so.7!wxGUIEventLoop::DoRun(wxGUIEventLoop * const this) (/home/ulrich/Development/wxWidgets/3.1.7/src/gtk/evtloop.cpp:61)
libwx_baseu-3.1.so.7!wxEventLoopBase::Run(wxEventLoopBase * const this) (/home/ulrich/Development/wxWidgets/3.1.7/src/common/evtloopcmn.cpp:87)
libwx_baseu-3.1.so.7!wxAppConsoleBase::MainLoop(wxAppConsoleBase * const this) (/home/ulrich/Development/wxWidgets/3.1.7/src/common/appbase.cpp:377)
libwx_baseu-3.1.so.7!wxAppConsoleBase::OnRun(wxAppConsoleBase * const this) (/home/ulrich/Development/wxWidgets/3.1.7/src/common/appbase.cpp:298)
libwx_gtk3u_core-3.1.so.7!wxAppBase::OnRun(wxAppBase * const this) (/home/ulrich/Development/wxWidgets/3.1.7/src/common/appcmn.cpp:334)
libwx_baseu-3.1.so.7!wxEntry(int & argc, wxChar ** argv) (/home/ulrich/Development/wxWidgets/3.1.7/src/common/init.cpp:503)

libwx_baseu-3.1.so.7!wxEntry(int & argc, char ** argv) (/home/ulrich/Development/wxWidgets/3.1.7/src/common/init.cpp:515)

main(int argc, char ** argv) (/home/ulrich/Development/wxgui-testing/src/c2prog/wx/c2progapp.cpp:47)

Again the crash seems to happen on loading or creating a PNG bitmap, although the modal dialog itself does not have any explicit PNGs.

Looking at the debug console I see the following line:

Loaded '/snap/code/99/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-png.so'. Symbols loaded.

That is, the symbols of libpixbufloader-png were loaded, but in the callstack one sees:

libpixbufloader-png.so![Unknown/Just-In-Time compiled code] (Unknown Source:0 )

Isn't that strange? "Unknown Source", although the debugger claims to have loaded the symbols?

I guess there is indeed some sort of library conflict, but how do I find out which ones are in conflict?

I installed most development tools using "apt". However, I installed Visual Studio Code via the Ubuntu Software application which seems to use "snap". Could that cause problems?

Regards,

Ulrich

[Vadim Zeitlin]

On Wed, 22 Jun 2022 07:06:45 -0700 (PDT) utelle wrote:

u> I temporarily removed the radio buttons from the dialog. However, this
u> didn't solve the problem. I experienced a crash again on trying to show a
u> modal dialog.

Yes, this is almost certainly not related to wxRadioButton. How do you
build your application? Have you tried building the wx sample in the same
way, i.e. just take the sample code and paste it into one of your source
files, or, alternatively, build your application using the same compiler
command line that the sample uses?

u> Looking at the debug console I see the following line:
u>
u> Loaded
u> '/snap/code/99/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-png.so'.
u> Symbols loaded.
u>
u> That is, the symbols of libpixbufloader-png were loaded, but in the
u> callstack one sees:
u>
u> libpixbufloader-png.so![Unknown/Just-In-Time compiled code] (Unknown
u> Source:0 )
u>
u> Isn't that strange?

Yes, it is. I also have no idea where does this mention of JIT compiled
code come from, I had never seen this before.

u> I guess there is indeed some sort of library conflict, but how do I find
u> out which ones are in conflict?
u>
u> I installed most development tools using "apt". However, I installed Visual
u> Studio Code via the Ubuntu Software application which seems to use "snap".
u> Could that cause problems?

Normally the whole point of snaps is that they're isolated from the
system, so it shouldn't be the case, however I now wonder if your VS Code
also includes its own gcc used for compiling in it? If it is, this could
explain the problem. But it would be pretty weird and I would very much
hope that it uses the system compiler instead.

Also, just to be clear, does the program still crash if you run it from
outside VS Code? Do you see the same stack from gdb if you run it under it?

Regards,

[utelle]

Vadim Zeitlin schrieb am Mittwoch, 22. Juni 2022 um 17:18:20 UTC+2:

On Wed, 22 Jun 2022 07:06:45 -0700 (PDT) utelle wrote:

Yes, this is almost certainly not related to wxRadioButton.

 

I fear it has to do with how VS Code sets up the library search paths. At least it does weird things. For example, I installed the latest CMake version via Ubuntu Software aka snap, and I could invoke it from a terminal within VS Code without problems. However, when I tried to start the CMake build I got an error message about a bad CMake executable. Only after manually building and installing CMake it worked.

Yes, this is almost certainly not related to wxRadioButton. How do you
build your application?

Via the CMake tools extension in Visual Studio Code.

 

Have you tried building the wx sample in the same
way, i.e. just take the sample code and paste it into one of your source
files, or, alternatively, build your application using the same compiler
command line that the sample uses?

Not exactly. I used the Makefile tools of VS Code to build the sample. However, the same gcc version was used.

 

Normally the whole point of snaps is that they're isolated from the
system, so it shouldn't be the case, however I now wonder if your VS Code
also includes its own gcc used for compiling in it?

No, I have to configure the toolchain in VS Code

 

If it is, this could
explain the problem. But it would be pretty weird and I would very much
hope that it uses the system compiler instead.

I think the system compiler is used, but in fact I don't know what exactly VS Code does.

Also, just to be clear, does the program still crash if you run it from
outside VS Code? Do you see the same stack from gdb if you run it under it?

Now that was a good advice to test from outside VS Code. Guess what - the application does **not** crash - neither directly from the command line nor from gdb. There is a visual glitch in the arrangement of the dialog controls, but I think that is unrelated (I will start a new discussion for that).

 

In the meantime I built the very same application on my OpenSuSE VM. There all worked as expected. I could build and debug the application from within VS Code. No crash, no glitches.

However, I observed one strange subtlety: I built wxWidgets 3.1.7 on both platforms, Ubuntu 20.04 and OpenSuSE 15.3, in exactly the same way using

../configure --prefix=/home/ulrich/opt/wx317 --with-gtk --enable-debug

make

make install

Nevertheless, the libraries ended up in different folders:

OpenSuSe: /home/ulrich/opt/wx317/lib64

Ubuntu: /home/ulrich/opt/wx317/lib

That is, under OpenSuSE the folder name seems to indicate 64-bit, while under Ubuntu it seems to indicate 32-bit. Both systems are definitely 64-bit systems. So, why are the library folder names not identical? 

Regards,

Ulrich

[utelle]

In the meantime I deinstalled VS Code (that was installed via snap) and reinstalled it via apt. That worked flawlessly.

Then I rebuilt the application and started a debugging session within VS Code. Guess what - it worked! No crash!

Thanks a lot for the suggestion to start the application outside of VS Code. Obviously VS Code (or rather snap - or both) is to blame.

Regards,

Ulrich

[Vadim Zeitlin]

On Wed, 22 Jun 2022 09:26:16 -0700 (PDT) utelle wrote:

u> However, I observed one strange subtlety: I built wxWidgets 3.1.7 on both
u> platforms, Ubuntu 20.04 and OpenSuSE 15.3, in exactly the same way using
u>
u> ../configure --prefix=/home/ulrich/opt/wx317 --with-gtk --enable-debug
u> make
u> make install
u>
u> Nevertheless, the libraries ended up in different folders:
u>
u> OpenSuSe: /home/ulrich/opt/wx317/lib64
u> Ubuntu: /home/ulrich/opt/wx317/lib
u>
u> That is, under OpenSuSE the folder name seems to indicate 64-bit, while
u> under Ubuntu it seems to indicate 32-bit. Both systems are definitely
u> 64-bit systems. So, why are the library folder names not identical?

This must be OpenSuSE default for autoconf libdir, there is a possibility
to customize its behaviour globally, although I've never used it, so I
don't remember the details. You should be able to explicitly specify
--libdir option value if you don't want to use lib64 there, but normally it
shouldn't matter because `wx-config --libs` should still return the correct
path.

Glad to hear that you could resolve the main problem, I'm still not sure
what exactly happened there, but it seems that VS Code used a non-default
LD_LIBRARY_PATH or something like this, resulting in incompatible shared
libraries being loaded.

[utelle]

Vadim Zeitlin schrieb am Mittwoch, 22. Juni 2022 um 20:18:18 UTC+2:

On Wed, 22 Jun 2022 09:26:16 -0700 (PDT) utelle wrote:

u> OpenSuSe: /home/ulrich/opt/wx317/lib64
u> Ubuntu: /home/ulrich/opt/wx317/lib
u>
u> That is, under OpenSuSE the folder name seems to indicate 64-bit, while
u> under Ubuntu it seems to indicate 32-bit. Both systems are definitely
u> 64-bit systems. So, why are the library folder names not identical?

This must be OpenSuSE default for autoconf libdir,

Ah, ok, that explains it.

 

there is a possibility
to customize its behaviour globally, although I've never used it, so I
don't remember the details. You should be able to explicitly specify

--libdir option value if you don't want to use lib64 there, ...

I'm fine with lib64. I was just curious to know whether this has some sort of side effect or not.

 

Glad to hear that you could resolve the main problem,

Yeah, I'm really relieved. That problem cost me quite a few grey hairs...

 

I'm still not sure
what exactly happened there, but it seems that VS Code used a non-default
LD_LIBRARY_PATH or something like this, resulting in incompatible shared
libraries being loaded.

I still find it strange that I didn't find any hints about this potential incompatibility, since installing VS Code and CMake via snap led to the situation that the CMake executable was not usable from within VS Code. Maybe the pros never install their tools via snap, and it was simply my own fault to choose the alleged easy route...

Thanks again for bearing with me to solve the puzzle.

Regards,

Ulrich