pidgin/pidgin

Fix a crash when hovering over an exceptionally long URL (4074 characters,
release-2.x.y
2014-01-13, Mark Doliner
2bb66ef1475e
Fix a crash when hovering over an exceptionally long URL (4074 characters,
but it might be different for you) in a gtkimhtml widget (such as the IM
window).

This was reported on the support mailing list:
http://pidgin.im/pipermail/support/2013-March/012980.html
http://pidgin.im/pipermail/support/2013-March/012981.html

Repro steps:
1. "gdb pidgin"

2. "break gdk_x_error"
You'll probably need to type "y" to make breakpoint pending on future shared library load. (Or you could run first then add the breakpoint.)

3. "run --sync"
--sync probably isn't actually necessary. Theoretically it should make the backtrace more useful. Like, maybe it could actually show the Pidgin calls that trigger the problem? Or maybe the problem call starts from the gtk main loop, so there would never be Pidgin code in the backtrace? It's also possible we don't pass our args to the right places to make --sync work.

4. "cont"
I hit the breakpoint at startup for some reason. I've just been continuing past it. Doesn't seem to affect anything.

5. Open an IM window.

6. Paste a long URL.

7. Mouse over the long URL.

8. The breakpoint is hit.

9. "bt"

#0 gdk_x_error (display=0x740e30, error=0x7fffffffbc20)
at /build/buildd/gtk+2.0-2.24.13/gdk/x11/gdkmain-x11.c:458
#1 0x00007ffff73b94f6 in _XError () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#2 0x00007ffff73b6741 in ?? () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#3 0x00007ffff73b6785 in ?? () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#4 0x00007ffff73b7378 in _XReply () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#5 0x00007ffff73b2d3d in XSync () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#6 0x00007ffff73b2dcb in ?? () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#7 0x00007ffff73b9e2f in ?? () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#8 0x00007ffff7395d14 in XCreatePixmap () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#9 0x00007ffff62bd0d2 in _gdk_pixmap_new (drawable=0x186ec60, width=width@entry=32774, height=25, depth=24,
depth@entry=-1) at /build/buildd/gtk+2.0-2.24.13/gdk/x11/gdkpixmap-x11.c:175
#10 0x00007ffff6289617 in IA__gdk_pixmap_new (drawable=drawable@entry=0x186ec60, width=width@entry=32774,
height=, depth=depth@entry=-1) at /build/buildd/gtk+2.0-2.24.13/gdk/gdkpixmap.c:249
#11 0x00007ffff6297036 in gdk_window_begin_implicit_paint (rect=0x7fffffffbed0, window=0x186ec60)
at /build/buildd/gtk+2.0-2.24.13/gdk/gdkwindow.c:2779
#12 gdk_window_process_updates_internal (window=0x186ec60) at /build/buildd/gtk+2.0-2.24.13/gdk/gdkwindow.c:5574
#13 0x00007ffff6299201 in IA__gdk_window_process_all_updates ()
at /build/buildd/gtk+2.0-2.24.13/gdk/gdkwindow.c:5696
#14 0x00007ffff6299269 in gdk_window_update_idle (data=)
at /build/buildd/gtk+2.0-2.24.13/gdk/gdkwindow.c:5322
#15 0x00007ffff6276e77 in gdk_threads_dispatch (data=0x1a45c40) at /build/buildd/gtk+2.0-2.24.13/gdk/gdk.c:512
#16 0x00007ffff53d8ab5 in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#17 0x00007ffff53d8de8 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#18 0x00007ffff53d91e2 in g_main_loop_run () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#19 0x00007ffff663ec77 in IA__gtk_main () at /build/buildd/gtk+2.0-2.24.13/gtk/gtkmain.c:1271
#20 0x0000000000499950 in main (argc=1, argv=0x7fffffffe538) at gtkmain.c:933

This is the message it prints when it exits:
The program 'Pidgin' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadAlloc (insufficient resources for operation)'.
(Details: serial 14454 error_code 11 request_code 53 minor_code 0)
(Note to programmers: normally, X errors are reported asynchronously;
that is, you will receive the error a while after causing it.
To debug your program, run it with the --sync command line
option to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error() function.)

I think it's kinda lame that gdk/gtk/xlib/whatever barfs when we give it a
ridiculously wide pango layout, but whatever. I'm assuming this problem is
gtkimhtml specific, and so I don't want to spend a whole lot of time fixing
it. As an easy fix I want to just truncate the URL displayed in the tooltip
to 200 characters.

Here's an example URL that I used to trigger the crash:
http://www.example.com/?%30123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789%30123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789%30123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789%30123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789%30123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789%30123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789%30123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789%30123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789%30123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789%30123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789%30123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789%30123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789%30123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789%30123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789%30123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789%30123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789%30123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789%30123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789%30123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789%30123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789%30123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789%30123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789%30123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789%30123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789%30123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789%30123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789%30123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789%30123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789%30123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789%30123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789%30123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789%30123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789%30123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789%30123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789%30123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789%30123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789%30123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789%30123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789%30123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789%3012345678901234567890123456789012345678901234567890123456789012345678
/** @page plugin-i18n Third Party Plugin Translation Support
@section Introduction
For the purpose of this document we're going to assume that your plugin:
- Is set up to use autotools. It may be possible to add translation support
without autotools, but we have no idea how. We may not want to know, either ;)
- Has an autogen.sh. You may have also called this bootstrap.sh or similar.
- Resides in a source tree that has @c configure.ac and @c Makefile.am in the
top-level directory as well as a @c src directory in which the plugin's source
is located. A @c Makefile.am should also exist in the @c src directory.
For a plugin to have translation support there are a few steps that need to
followed:
- In your autogen.sh, add the following after your other utility checks:
@code
(intltoolize --version) < /dev/null > /dev/null 2>&1 || {
echo;
echo "You must have intltool installed to compile <YOUR PLUGIN NAME>";
echo;
exit;
}
@endcode
Then before your call to aclocal add:
@code
intltoolize --force --copy
@endcode
- Now edit configure.ac and add the following:
@code
AC_PROG_INTLTOOL
GETTEXT_PACKAGE=<YOUR PLUGIN NAME>
AC_SUBST(GETTEXT_PACKAGE)
AC_DEFINE_UNQUOTED(GETTEXT_PACKAGE, ["$GETTEXT_PACKAGE"], [Define the gettext package to be used])
ALL_LINGUAS=""
AM_GLIB_GNU_GETTEXT
@endcode
The position of these macros in the file don't really matter, but if you
have issues either play around with it or feel free to ask one of the Pidgin
developers. Finally add 'po/Makefile.in' to you 'AC_OUTPUT' command.
- Now create a directory named 'po'.
- 'cd' into the 'po' directory.
- Create/edit the file 'POTFILE.in' in your favorite editor. Each line
should be the name of a file that could or does have strings marked for
translating (we're getting to that step). These file names should be
relative to the top directory of your plugin's source tree.
- 'cd' back to the top directory of your plugin's source tree.
- Open 'Makefile.am' and add 'po' to your 'SUBDIRS' variable.
- While still in the top directory of your plugin's source tree, execute
'intltool-prepare'. This will setup anything extra that intltool needs.
- Fire off 'autogen.sh' and when it's completed, verify that you have a
'po/POTFILES' (notice the lack of a .in). If you do, everything should be
set on the autotools side.
- Take a break, stretch your legs, smoke a cigarette, whatever, because
we're done with the autotools part.
- When you're ready, 'cd' into the directory with the source files for your
plugin.
- Open the file containing the PurplePluginInfo structure.
- If you're not already, please make sure that you are including the
'config.h' file for you plugin. Note that 'config.h' could be whatever
you told autohead to use with AM_CONFIG_HEADER. Also add the following:
@code
#include <glib/gi18n-lib.h>
@endcode
Make sure that this include is after you include of your 'config.h',
otherwise you will break your build. Also note that if you wish to
maintain compatibility with older versions of GLib, you will need to
include additional preprocessor directives, which we won't cover here.
- This is where things get a bit goofy. libpurple is going to try to
translate our strings using the libpurple gettext package. So we have to
convert them before libpurple attempts to.
- To do this, we're going to change the entries for name, summary, and
description to NULL.
- Next, locate your 'init_plugin' function. Your name for this function
may vary, but it's the second parameter to 'PURPLE_INIT_PLUGIN'.
- Now add the following within your 'init_plugin' function:
@code
#ifdef ENABLE_NLS
bindtextdomain(GETTEXT_PACKAGE, LOCALEDIR);
bind_textdomain_codeset(GETTEXT_PACKAGE, "UTF-8");
#endif /* ENABLE_NLS */
info.name = _("<YOUR PLUGIN NAME>");
info.summary = _("<YOUR PLUGIN SUMMARY>");
info.description = _("<YOUR PLUGIN DESCRIPTION>");
@endcode
Note that the _() is intentional, and that it is telling intltool that
this string should be translated. There is also N_() which says that a
string should only be marked for translation but should not be translated
yet.
- Go through the rest of your code and mark all the other strings for
translation with _().
- When thats done, feel free to commit your work, create your po template
(pot file) or whatever.
- To create you po template, 'cd' to 'po' and execute:
@code
intltool-update --pot
@endcode
- To add new translations to your plugin, all you have to do is add the
language code to the 'ALL_LINGUAS' variable in your configure.ac. Take
note that this list of languages should be separated by a space. After
you have added the language code to 'ALL_LINGUAS', drop the xx.po file
into 'po', and re-'autogen.sh'. After a full build you should now be
able to use the translation.
*/