Re: Unhandled exception?

[Chris Vine <chris cvine freeserve co uk>]

On Mon, 26 May 2014 15:03:47 -0400
Phillip Susi <psusi ubuntu com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> On 05/22/2014 12:52 PM, Kjell Ahlstedt wrote:
> > The gtkmm tutorial contains a section that describes how to use the
> > gdb debugger to see where an exception is thrown in a signal
> > handler.
> >
> > https://developer.gnome.org/gtkmm-tutorial/stable/sec-exceptions-in-signal-handlers.html.en
>
> Thanks... so it seems the problem is that Glib::IOChannel::read() is
> throwing the exception because dosfsck is spitting out a 0xBD
> character.  It seems that in CP 437, that is a 1/2 chracter, but in
> UTF-8 it is an incomplete multi byte sequence.  This leads me to
> conclude that there is a bug in glibmm, and I have a question on how
> to handle this character.  The question is how to have
> IOChannel::read treat its input as CP-437 instead of UTF-8, and the
> bug:
>
> glibmm seems to have an automatic exception catch that prints a
> warning and attempts to continue.  This is wrong.  An unhandled
> exception should terminate the program.  By eating the exception,
> glibmm has caused gparted's call stack to unwind leaving the program
> in a broken state.

If you set the IOChannel's encoding to "" using
Glib::IOChannel::set_encoding() immediately after creation it should
accept binary data.  Are you saying that that doesn't work?  If it
doesn't it is certainly a bug, as it works with the unwrapped
g_io_channel_set_encoding() when passed a NULL argument.  (In which
case, I guess you could use g_io_channel_set_encoding() on the
underlying GIOChannel object.)

However, if you have a file descriptor and you are handling binary data
why use a IOChannel at all?  Why not connect the file descriptor to the
main loop using Glib::signal_io().connect() and read the file
descriptor using standard (unix) read().

Chris