After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 521294 - Impossible to catch ConvertError exception
Impossible to catch ConvertError exception
Product: glibmm
Classification: Bindings
Component: general
Other Linux
: Normal major
: ---
Assigned To: gtkmm-forge
Depends on: 521591
Reported: 2008-03-09 02:00 UTC by Jonathon Jongsma
Modified: 2008-03-11 15:44 UTC
See Also:
GNOME target: ---
GNOME version: ---

test case illustrating the uncatchable exception. (1.37 KB, text/plain)
2008-03-09 02:03 UTC, Jonathon Jongsma
Details (1.56 KB, text/plain)
2008-03-09 13:09 UTC, Murray Cumming

Description Jonathon Jongsma 2008-03-09 02:00:33 UTC
When using Glib::Markup::Parser to parse a GMarkup document, if it encounters invalid UTF-8, it throws an exception which seemingly can't be caught.  I don't understand why, but I can't seem to catch it.  Test case attached.
Comment 1 Jonathon Jongsma 2008-03-09 02:03:03 UTC
Created attachment 106878 [details]
test case illustrating the uncatchable exception.

When I run the attached program, I get the following output, even though I'm attempting to catch instances of Glib::MarkupError, Glib::ConvertError, and Glib::Error:

Glib::MarkupError: terminate called after throwing an instance of 'Glib::ConvertError'
Aborted (core dumped)
Comment 2 Murray Cumming 2008-03-09 13:08:40 UTC
Yes, I get that too, and I can't understand why. Here is a slightly changed test case to make it even more obvious, and here is the gdb backtrace:

murrayc@murrayc-laptop:~$ gdb ./a.out 
GNU gdb 6.6-debian
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...
Using host libthread_db library "/lib/tls/i686/cmov/".
(gdb) run
Starting program: /home/murrayc/a.out 
debug: before parsing
Glib::MarkupError: terminate called after throwing an instance of 'Glib::ConvertError'

Program received signal SIGABRT, Aborted.
0xffffe410 in __kernel_vsyscall ()
(gdb) bt
  • #0 __kernel_vsyscall
  • #1 raise
    from /lib/tls/i686/cmov/
  • #2 abort
    from /lib/tls/i686/cmov/
  • #3 __gnu_cxx::__verbose_terminate_handler
    from /usr/lib/
  • #4 ??
    from /usr/lib/
  • #5 std::terminate
    from /usr/lib/
  • #6 __cxa_throw
    from /usr/lib/
  • #7 Glib::ConvertError::throw_func
    from /usr/lib/
  • #8 Glib::Error::throw_exception
    from /usr/lib/
  • #9 Glib::locale_from_utf8
    from /usr/lib/
  • #10 Glib::operator<<
    from /usr/lib/
  • #11 main

Comment 3 Murray Cumming 2008-03-09 13:09:13 UTC
Created attachment 106900 [details]
Comment 4 Murray Cumming 2008-03-09 13:27:23 UTC
Actually, it's operator<< that is throwing the exception. I wonder if that's happening when writing out the exception's what() message.
Comment 5 Jonathon Jongsma 2008-03-09 13:54:49 UTC
Indeed you're correct.  I guess I hadn't looked closely enough.  I can get it to not abort if I instead use the following line:
        std::cerr << "Glib::MarkupError: " << exception.what ().raw () << std::endl;

(e.g. using the raw() string and not doing any charset conversions on operator<<).  I wonder if it's really a good idea to put invalid utf-8 into a utf-8 message string...
Comment 6 Jonathon Jongsma 2008-03-09 19:50:21 UTC
just for reference, this is the output I get with the raw() call above (assuming bugzilla doesn't do something weird to it):

debug: before parsing
Glib::MarkupError: Error on line 1 char 6: Invalid UTF-8 encoded text - not valid '�`���اH�޿��'
Comment 7 Murray Cumming 2008-03-10 12:24:53 UTC
I consider this a glib bug, because I think that GError messages are meant to be displayed, so they should be valid UTF8. I'll make a C test case and file it eventually if you don't first.
Comment 8 Murray Cumming 2008-03-11 15:44:36 UTC
I fixed this in glib in bug 521591.