putty triggers GLib-CRITICAL Source ID not found on console

This happens once per character typed in putty.

I can reproduce this in 0.63-4 (built from Ubuntu source) on Xubuntu 14.04 if I start a serial session, set "Local echo" to "Force on", and press some keys.

Setting a breakpoint on g_log I get this backtrace:

#0 0x00007ffff683fcf0 in g_log () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#1 0x00007ffff6837c5c in g_source_remove ()
   from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2 0x0000000000467a75 in timer_change_notify (next=2367632)
    at unix/gtkwin.c:1431
#3 0x0000000000458899 in schedule_timer (ticks=ticks@entry=20,
    fn=fn@entry=0x44fe30 <term_timer>, ctx=ctx@entry=0xa15200) at timing.c:145
#4 0x000000000044d1f0 in term_schedule_update (term=term@entry=0xa15200)
    at terminal.c:1101
#5 0x000000000045819e in term_schedule_update (term=0xa15200)
    at terminal.c:1099
#6 seen_disp_event (term=0xa15200) at terminal.c:1112
#7 term_reset_cblink (term=0xa15200) at terminal.c:1151
#8 term_data (term=0xa15200, is_stderr=is_stderr@entry=0,
    data=data@entry=0xa5d8b0 "aw<\366\377\177", len=len@entry=1)
    at terminal.c:6136
#9 0x000000000046729c in from_backend (frontend=<optimised out>,
    is_stderr=is_stderr@entry=0, data=data@entry=0xa5d8b0 "aw<\366\377\177",
    len=len@entry=1) at unix/gtkwin.c:210
#10 0x0000000000415801 in c_write (ldisc=0x90f9a0, len=<optimised out>,
    buf=0xa5d8b0 "aw<\366\377\177") at ldisc.c:26
#11 ldisc_send (handle=handle@entry=0x90f9a0,
    buf=buf@entry=0xa5d8b0 "aw<\366\377\177", len=<optimised out>,
    interactive=interactive@entry=1) at ldisc.c:314
#12 0x0000000000415bac in luni_send (handle=handle@entry=0x90f9a0,
    widebuf=widebuf@entry=0xab1a10 L"a翿\xa5d8a0", len=1,
    interactive=interactive@entry=1) at ldiscucs.c:96
#13 0x0000000000415c23 in lpage_send (handle=handle@entry=0x90f9a0,
    codepage=codepage@entry=55, buf=buf@entry=0x966e40 "a", len=1,
    interactive=interactive@entry=1) at ldiscucs.c:32
#14 0x0000000000466df6 in input_method_commit_event (imc=<optimised out>,
    str=0x966e40 "a", data=0x6d86b0) at unix/gtkwin.c:1227
#15 0x00007ffff6b0af29 in g_cclosure_marshal_VOID__STRINGv ()
   from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#16 0x00007ffff6b085e7 in ?? ()
   from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#17 0x00007ffff6b21088 in g_signal_emit_valist ()
   from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#18 0x00007ffff6b22212 in g_signal_emit_by_name ()
   from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#19 0x00007ffff6b0af29 in g_cclosure_marshal_VOID__STRINGv ()
   from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#20 0x00007ffff6b085e7 in ?? ()
   from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#21 0x00007ffff6b21088 in g_signal_emit_valist ()
   from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#22 0x00007ffff6b21ce2 in g_signal_emit ()
   from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#23 0x00007ffff6b0af29 in g_cclosure_marshal_VOID__STRINGv ()
   from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#24 0x00007ffff6b085e7 in ?? ()
   from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#25 0x00007ffff6b21088 in g_signal_emit_valist ()
   from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#26 0x00007ffff6b22212 in g_signal_emit_by_name ()
  ...

...in fact I see this clutch of upstream fixes *was* already backported to the Debian/Ubuntu packages as of 0.63-6, so this bug is already fixd in Utopic (14.10) and Vivid (15.04).

Status changed to 'Confirmed' because the bug affects multiple users.