As of version 2023.x.x.x : An Assertion Failed! * 6

[Scott Cowles Jacobs]

Until version 2023.x.x.x, I have not had the following occur.

Now, each time the stitching process runs, there are 6 times that a PTBatcherGUI window appears that is headlined "An assertion failed!"
Dismissing the first two causes the stitching to start and eventually to conclude successfully, but there are 4 additional windows.
I believe that for each panorama stitched, the backtraces are the same - that is, the first backtrace for panorama #1 is the same as the backtrace for panorama #2, the second backtrace for #1 is the same as for #2, etc.

It appears that the assertion is the same for all six windows, and that in fact, there are only three different backtraces, each repeated twice (#1==#2, #3==#4, #5==#6)

ASSERT INFO:
/usr/include/wx-3.2/wx/strvararg.h(484): assert "(argtype & (wxFormatStringSpecifier<T>::value)) == argtype" failed in wxArgNormalizer(): format specifier doesn't match argument type

The first two backtraces contain only:
[1] wxEntry(int&, wchar_t**)
[2] __libc_start_main

#3/#4 add:
[1] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&)
[2] wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*)
[3] wxEvtHandler::TryHereOnly(wxEvent&)
[4] wxEvtHandler::ProcessEventLocally(wxEvent&)
[5] wxEvtHandler::ProcessEvent(wxEvent&)
[6] wxEvtHandler::SafelyProcessEvent(wxEvent&)
[7] wxTimerImpl::SendEvent()
[8] g_main_loop_run
[9] gtk_main
[10] wxGUIEventLoop::DoRun()
[11] wxEventLoopBase::Run()
[12] wxAppConsoleBase::MainLoop()
after the above (numbers, of course, different)

#5/#6 add two more sets (total of 3) of:
[1] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&)
[2] wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*)
[3] wxEvtHandler::TryHereOnly(wxEvent&)
[4] wxEvtHandler::ProcessEventLocally(wxEvent&)
[5] wxEvtHandler::ProcessEvent(wxEvent&)

but with a slightly different preface:
[16] wxEvtHandler::ProcessPendingEvents()
[17] wxAppConsoleBase::ProcessPendingEvents()
[18] wxApp::DoIdle()
after the
[19] g_main_loop_run

instead of the earlier:
[6] wxEvtHandler::SafelyProcessEvent(wxEvent&)
[7] wxTimerImpl::SendEvent()

In case this explanation is confusing (likely!), I will [try to] attach a text file
joining all six backtraces.
I will also try to attach a video showing the stitch.
I may have to upload it to YouTube and just include the link...

==============================================================
Debian Testing / sway/testing,now 1.8.1-2 amd64 [installed]

Operating System: Linux 6.5.0-5-amd64 x86_64
Architecture: 64 bit
Free memory: 8485176 kiB

Hugin
Version: 2023.0.0.d88dc56ded0e
Path to resources: /usr/share/hugin/xrc/
Path to data: /usr/share/hugin/data/
Hugins camera and lens database: /home/scott/.local/share/hugin/camlens.db
Multi-threading using C++11 std::thread and OpenMP

Libraries
wxWidgets: wxWidgets 3.2.4
wxWidgets Library (wxGTK port)
Version 3.2.4 (Unicode: wchar_t, debug level: 1),
Runtime version of toolkit used is 3.24.
Compile-time GTK+ version is 3.24.38.

libpano13: 2.9.22
Boost: 1.83.0
Exiv2: 0.27.6
SQLite3: 3.44.2
Vigra: 1.11.1
LittleCMS2: 2.14

[tmodes (tmodes)]

Fixed in repository (changeset 2b2251f51580).

(The bug was in an old code. Maybe wxWidgets has become more pedantic in its check to earlier version.)

[Scott Cowles Jacobs (scott092707)]

How difficult is it to compile/install Hugin from your site - I've only so far used whatever version is newest in Debian Testing (usually quite current...), but Hugin versions tend to come out late in the year, and I would find using Hugin more pleasant not having to dismiss six error/warning windows per stitch...