Hi Samuel,
Thanks for the quick response.
On Thu, May 01, 2014 at 08:22:36PM +0200, Samuel Thibault wrote:
> I have updated espeakedit to the latest upstream revision, 1.48.03,
> which already includes almost all wxwidgets 3.0 fixes. I have kept the
> missing ones as patches. Bumping the build-dependency to wxwidgets 3.0
> however brings a startup issue:
>
> An assertion failed!
>
> ../src/gtk/font.cpp(337): assert "IsOk()" failed in GetPointSize():
> invalid font
>
> Backtrace:
>
> wxFont::GetPointSize() const
> wxEntry(int&, wchar_t**)
> __libc_start_main
>
> and then the interface seems to show up fine, but I'd rather avoid
> uploading that. Would you have any idea about what is going wrong? I
> really don't know much about wxwidgets.
I'd guess GetPointSize() is being called on a wxFont object which hasn't
yet been set up properly.
It looks like you didn't transfer the -DNDEBUG addition from the patch I
attached. Some background:
There's a __WXDEBUG__ mode in wx which does additional verification of
parameters passed, etc to detect invalid use of the API. If this isn't
turned on, then the wx library will try to do something sensible. In
this case, it just returns 0 - from src/gtk/font.cpp:
int wxFont::GetPointSize() const
{
wxCHECK_MSG( Ok(), 0, wxT("invalid font") );
return M_FONTDATA->HasNativeFont() ?
M_FONTDATA->m_nativeFontInfo.GetPointSize()
: M_FONTDATA->m_pointSize;
}
One of the changes in 3.0 is that this mode is now on by default. For
2.8 there's a special build in Debian with a -dbg suffix (this predates
the -dbg for detached debug symbols convention), but you have to rebuild
the application against this, so almost nobody uses it as far as I can
tell.
You can turn off this debug mode at *application* build time with
-DNDEBUG. This does mean that the assertion just gets quietly ignored,
but that's no different to what happens in the current build of
espeakedit in Debian.
For my own application (survex), I had previously tested with the debug
build of 2.8, so after the switch to 3.0 I left debug on and found users
gradually hit more assertions in obscure cases (which I've addressed as
they were reported). None of them actually seemed to cause problems
with debug off, so at least anecdotally the -DNDEBUG hammer seems a
reasonable approach. I'm not sure the inconvenience to users or the
time I've spent fixing these issues has really been worthwhile.
Cheers,
Olly
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
