Automatic CDDB search causes segfault with LANG=ja_JP.UTF-8 and "freedb.freedb.org" server

[STGSAGWAN]

Binary package hint: easytag

Automatic CDDB search causes segfault when LANG is ja_JP.UTF-8 and the CDDB servers include "freedb.freedb.org".

1)
$ lsb_release -rd
Description: Ubuntu 10.04.1 LTS
Release: 10.04

2)
$ LANG=C apt-cache policy easytag
easytag:
  Installed: 2.1.6-1ubuntu1
  Candidate: 2.1.6-1ubuntu1
  Version table:
 *** 2.1.6-1ubuntu1 0
        500 http://jp.archive.ubuntu.com/ubuntu/ lucid/universe Packages
        100 /var/lib/dpkg/status

3) What to be expected to happen:
Automatic CDDB search is done successfully.

4) What happened instead:
Automatic CDDB search causes segfault.

$ grep cddb_server_name ~/.easytag/easytagrc
cddb_server_name_automatic_search=freedb.freedb.org
cddb_server_name_automatic_search2=freedb.musicbrainz.org
cddb_server_name_manual_search=www.gnudb.org

$ LANG=ja_JP.UTF-8 easytag
EasyTAG 2.1.6: 異常終了しました！ (PID: 1637).
シグナル SIGSEGV (11) を受け取りました
EasyTAG でバグと思われるものが見つかりました。gdb によるバックトレースのログ (`gdb easytag core` して 'bt' と 'l' コマンドの結果) を <email address hidden> までメールして下さい。
Segmentation fault

$ dmesg | tail -1
[ 714.935664] easytag[1637]: segfault at 38 ip 00faf50b sp bfa04d2c error 4 in libc-2.11.1.so[f6f000+153000]

$ gdb -q easytag
Reading symbols from /usr/bin/easytag...(no debugging symbols found)...done.
(gdb) run
Starting program: /usr/bin/easytag
[Thread debugging using libthread_db enabled]

Program received signal SIGSEGV, Segmentation fault.
0x00bb450b in vfprintf () from /lib/tls/i686/cmov/libc.so.6
(gdb) bt
#0 0x00bb450b in vfprintf () from /lib/tls/i686/cmov/libc.so.6
#1 0x00c55e62 in __vasprintf_chk () from /lib/tls/i686/cmov/libc.so.6
#2 0x008c6abf in g_vasprintf () from /lib/libglib-2.0.so.0
#3 0x008a5506 in g_strdup_vprintf () from /lib/libglib-2.0.so.0
#4 0x008a5528 in g_strdup_printf () from /lib/libglib-2.0.so.0
#5 0x0806f170 in ?? ()
#6 0x0081bdcc in g_cclosure_marshal_VOID__VOID ()
   from /usr/lib/libgobject-2.0.so.0
#7 0x0080e252 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#8 0x0082299d in ?? () from /usr/lib/libgobject-2.0.so.0
#9 0x00823db4 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
#10 0x00824256 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#11 0x001adc7a in gtk_button_clicked () from /usr/lib/libgtk-x11-2.0.so.0
#12 0x001af238 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#13 0x0081bdcc in g_cclosure_marshal_VOID__VOID ()
   from /usr/lib/libgobject-2.0.so.0
#14 0x0080c8b9 in ?? () from /usr/lib/libgobject-2.0.so.0
#15 0x0080e252 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#16 0x0082223a in ?? () from /usr/lib/libgobject-2.0.so.0
#17 0x00823db4 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
#18 0x00824256 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#19 0x001add1a in gtk_button_released () from /usr/lib/libgtk-x11-2.0.so.0
#20 0x001add63 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
---Type <return> to continue, or q <return> to quit---
#21 0x0026b424 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#22 0x0080c8b9 in ?? () from /usr/lib/libgobject-2.0.so.0
#23 0x0080e252 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#24 0x008225e6 in ?? () from /usr/lib/libgobject-2.0.so.0
#25 0x00823c33 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
#26 0x00824256 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#27 0x00398636 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#28 0x00263a5d in gtk_propagate_event () from /usr/lib/libgtk-x11-2.0.so.0
#29 0x00264e07 in gtk_main_do_event () from /usr/lib/libgtk-x11-2.0.so.0
#30 0x0055939a in ?? () from /usr/lib/libgdk-x11-2.0.so.0
#31 0x008825e5 in g_main_context_dispatch () from /lib/libglib-2.0.so.0
#32 0x008862d8 in ?? () from /lib/libglib-2.0.so.0
#33 0x00886817 in g_main_loop_run () from /lib/libglib-2.0.so.0
#34 0x002653c9 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
#35 0x0808060b in ?? ()
#36 0x00b8abd6 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
#37 0x08054381 in ?? ()

The known Workarounds I've found so far:
Workaround 1: Start easytag with LANG=C.
Workaround 2: Use only freedb.musicbrainz.org for CDDB servers.

[STGSAGWAN (sakura-launchpad-bugreport)]

This crash has been found to be caused by the unmatched order of the message parameters in the file '/usr/share/locale/ja/LC_MESSAGES/easytag.mo' and the source code cddb.c:3290.
 (My thanks to forum member 'einundzwanzighundertsechs' at forums.ubuntulinux.jp)

/usr/share/locale/ja/LC_MESSAGES/easytag.mo:
msgid "Found %d matching album(s) for DiscID '%s'"
msgstr "DiscID '%s' に一致するアルバムが %d 個見つかりました"

cddb.c:
msg = g_strdup_printf(_("Found %d matching album(s) for DiscID '%s'"), g_list_length(CddbAlbumList),cddb_discid);

The aforementioned gdb backtrace "#5 0x0806f170 in ?? ()" was actually #5 0x0806f1d0 in Cddb_Search_Album_From_Selected_Files () at cddb.c:3290

[David King (amigadave)]

The forum post mentioned in comment #1 is: https://forums.ubuntulinux.jp/viewtopic.php?id=9425

[David King (amigadave)]

I fixed this in EasyTAG git, so it will be in the next release (2.1.9):

https://git.gnome.org/browse/easytag/commit/?id=35e57ca4829fb97221a76537b99dcc263ef549b2

The source string has changed, so the translated string will likely not be shown in the UI, but hopefully when the next Japanese translator comes along the fix will be preserved.

[David King (amigadave)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. However, I am closing it because the bug has been fixed in the latest development version of Ubuntu - Trusty Tahr.

This is a significant bug in Ubuntu. If you need a fix for the bug in previous versions of Ubuntu, please perform as much as possible of the SRU Procedure [1] to bring the need to a developer's attention.

[1]: https://wiki.ubuntu.com/StableReleaseUpdates#Procedure