Re: Unhandled exception?

[Chris Vine <chris cvine freeserve co uk>]

On Tue, 27 May 2014 10:24:26 +0100
Chris Vine <chris cvine freeserve co uk> wrote:
> 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().

Two subsidiary thoughts: as an alternative have you tried setting the
encoding to CP437? iconv() supports it on my system so glib ought to
also.

Secondly, on the issue of exceptions, if you are reading the IOChannel
in a callback in the glib main loop I suspect glibmm is swallowing the
exception in order to protect the main loop, although I haven't looked
at glibmm's wrapper for executing callbacks in the main loop for some
time so I could be wrong.  It is often better to swallow a throwing
callback and print to g_critical() than terminate the program, as you
can use g_log_set_always_fatal() to change the behaviour if you want.

If I am right about glibmm protecting the main loop, I would be
surprised if by swallowing the exception, glibmm caused gparted's call
stack to unwind.  You would expect that to do the opposite (and
exceptions can't propagate through glib's C layer to unwind the stack
anyway), albeit as you say probably rendering the program useless.

Chris