Another assert error message, this time in PTBatcherGUI

[Stefan Peter]

Sorry, but I got another one.

This has been observers using
Operating System: Linux 3.13.0-51-generic x86_64
Architecture: 64 bit
Free memory: 11436008 kiB

Hugin
Version: 2015.1.0.c0ae9038be6b
Path to resources: /usr/share/hugin/xrc/
Path to data: /usr/share/hugin/data/
Hugins camera and lens database: /home/stefan/.hugindata/camlens.db
Multi-threading using C++11 std::thread and OpenMP

Libraries
wxWidgets: wxWidgets 3.0
wxWidgets Library (wxGTK port)
Version 3.0.0 (Unicode: wchar_t, debug level: 1),
compiled at Dec 2 2013 15:56:33

Runtime version of toolkit used is 2.24.
Compile-time GTK+ version is 2.24.22.

libpano13: 2.9.19
Boost: 1.54.0
Exiv2: 0.23
SQLite3: 3.8.2
Vigra: 1.10.0

currently available from
https://launchpad.net/~hugin/+archive/ubuntu/nightly/+packages

Reproduce:
Loding an existing pto
Cange to the Sticher tab
Press "Stich!"
Confirm the save

Result:
ASSERT INFO:
../src/gtk/gauge.cpp(67): assert "0 <= m_gaugePos && m_gaugePos <= m_rangeMax" failed in DoSetGauge(): invalid gauge position in DoSetGauge()

BACKTRACE:
[1] wxGauge::DoSetGauge()
[2] ProgressStatusBar::ProgressStatusBar(wxWindow*, int, long, wxString const&)
[3] BatchFrame::OnCreateStatusBar(int, long, int, wxString const&)
[4] wxFrameBase::CreateStatusBar(int, long, int, wxString const&)
[5] BatchFrame::BatchFrame(wxLocale*, wxString)
[6] PTBatcherGUI::OnInit()
[7] wxEntry(int&, wchar_t**)
[8] main
[9] __libc_start_main
[10] _start

The error mesage windows states PTBatcherGUI, not hugin. I had to confirm the error message 10 of times until the stitch actually started.
I will make the pto available upon request.

With kind regards

Stefan Peter

[tmodes (tmodes)]

Should be fixed in changeset c0173a975f27.

At least somebody is testing the beta version ;-) and we don't get the reports after we have released the final version.

[Stefan Peter (s-peter-deactivatedaccount)]

Hi Thomas

On 05.05.2015 21:49, tmodes wrote:
> Should be fixed in changeset c0173a975f27.
>
> At least somebody is testing the beta version ;-) and we don't get the
> reports after we have released the final version.
>
> ** Changed in: hugin
> Status: New => Fix Committed
>
> ** Changed in: hugin
> Milestone: None => 2015.0beta2
>

Sorry, now I get a couple of

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

BACKTRACE:
[1] HuginQueue::detail::PrintDetailInfo(HuginBase::Panorama const&,
HuginBase::PanoramaOptions const&, std::set<unsigned int,
std::less<unsigned int>, std::allocator<unsigned int> > const&, wxString
const&, wxString const&, wxConfigBase*, double&)
[2] HuginQueue::GetStitchingCommandQueue(HuginBase::Panorama const&,
wxString const&, wxString const&, wxString const&, wxString&,
wxArrayString&, wxArrayString&)
[3] RunStitchPanel::StitchProject(wxString, wxString)
[4] RunStitchFrame::StitchProject(wxString, wxString)
[5] Batch::OnStitch(wxString, wxString, int)
[6] Batch::RunNextInBatch()
[7] Batch::RunBatch()
[8] BatchFrame::RunBatch()
[9] PTBatcherGUI::OnInit()
[10] wxEntry(int&, wchar_t**)
[11] main
[12] __libc_start_main
[13] _start

from
Operating System: Linux 3.13.0-52-generic x86_64
Architecture: 64 bit
Free memory: 10428204 kiB

Hugin
Version: 2015.1.0.246eb732c486
Path to resources: /usr/share/hugin/xrc/
Path to data: /usr/share/hugin/data/
Hugins camera and lens database: /home/stefan/.hugindata/camlens.db
Multi-threading using C++11 std::thread and OpenMP

Libraries
wxWidgets: wxWidgets 3.0
wxWidgets Library (wxGTK port)
Version 3.0.0 (Unicode: wchar_t, debug level: 1),
compiled at Dec 2 2013 15:56:33

Runtime version of toolkit used is 2.24.
Compile-time GTK+ version is 2.24.22.

libpano13: 2.9.19
Boost: 1.54.0
Exiv2: 0.23
SQLite3: 3.8.2
Vigra: 1.10.0

I'm feeling tempted to replace the 3.0.0 wxWidgets with the old ones.

Regards

Stefan Peter

--
Any technology that does not appear magical is insufficiently advanced."
~ Gregory Benford

[tmodes (tmodes)]

Should also be fixed in repository.

See http://docs.wxwidgets.org/3.0.0/overview_debugging.html for more information about the assert message.
(Maybe defining the symbol NDEBUG is sufficient to suppress the assert messages?)

[Stefan Peter (s-peter-deactivatedaccount)]

Dear Thomas Modes

On 06.05.2015 18:15, tmodes wrote:
> Should also be fixed in repository.

Yes, I can confirm that I can not anymore reproduce this error using
Operating System: Linux 3.13.0-52-generic x86_64
Architecture: 64 bit
Free memory: 11166756 kiB

Hugin
Version: 2015.1.0.15309c132690
Path to resources: /usr/share/hugin/xrc/
Path to data: /usr/share/hugin/data/
Hugins camera and lens database: /home/stefan/.hugindata/camlens.db
Multi-threading using C++11 std::thread and OpenMP

Libraries
wxWidgets: wxWidgets 3.0
wxWidgets Library (wxGTK port)
Version 3.0.0 (Unicode: wchar_t, debug level: 1),
compiled at Dec 2 2013 15:56:33

Runtime version of toolkit used is 2.24.
Compile-time GTK+ version is 2.24.22.

libpano13: 2.9.19
Boost: 1.54.0
Exiv2: 0.23
SQLite3: 3.8.2
Vigra: 1.10.0

>
> See http://docs.wxwidgets.org/3.0.0/overview_debugging.html for more information about the assert message.
> (Maybe defining the symbol NDEBUG is sufficient to suppress the assert messages?)

I may be tempted to investigate this for the upcoming RC versions. On
the other hand, as long as you don't object, I feel that these asserts
are there for a reason. The more of these we can fix now, the less
problems we will encounter in the future on all of the systems we want
to deploy to.

So, as long as I don't get a "shut up, you are annoying me with your
nitpicking" from you, I will continue with the DEBUG variant of
hugin/wxwidgets during the beta versions, I will reconsider this
decision for the rc releases.

Thank you very much for your support.

With kind regards

Stefan Peter

--
Any technology that does not appear magical is insufficiently advanced."
~ Gregory Benford

[tmodes (tmodes)]

Hi Stephan,

> Yes, I can confirm that I can not anymore reproduce this error using

Nice to hear.

> On the other hand, as long as you don't object, I feel that these asserts
> are there for a reason. The more of these we can fix now, the less
> problems we will encounter in the future on all of the systems we want
> to deploy to.

I see this the same way. I hope they help us to strengthen our code.

> So, as long as I don't get a "shut up, you are annoying me with your
> nitpicking" from you, I will continue with the DEBUG variant of ..

As long as the same message is not reported more than once or even often I don't cry "shut up".
I will do what is in my capability to fix them.

[Stefan Peter (s-peter-deactivatedaccount)]

Hi Thomas

On 07.05.2015 20:12, tmodes wrote:
>> So, as long as I don't get a "shut up, you are annoying me with your
>> nitpicking" from you, I will continue with the DEBUG variant of ..
>
> As long as the same message is not reported more than once or even often I don't cry "shut up".
> I will do what is in my capability to fix them.
>

I really appreciate this.

With kind regards

Stefan Peter

--
Any technology that does not appear magical is insufficiently advanced."
~ Gregory Benford