Help with Chromium crash

[DrK]

Hello,

Hopefully this is the right place to post; if not, sorry.

I'm experiencing a weird and not always reproductible crash in
Chromium 5.0.375.125 under Ubuntu 10.04: it seems that sometimes,
when trying to download a file and the "Save as" dialog pops up,
Chromium tries to allocate 15GB (?!) of memory and fails with an out
of memory assert.

I've built a debug version of the browser and I managed to get a
backtrace, see the link below:

http://pastebin.com/NNgCknLM

I can't reproduce it at the moment, but will try to determine which
combination of open tabs triggers this (because it's not a single tab
by itself that causes the problem, apparently).

So can you guys look at the backtrace and give me some feedback, maybe
some things to try, etc. ?

Thanks!

[DrK]

This is the log from the console:

http://pastebin.com/AeRjVQVp

[Chris Evans]

Nice. Looks like you've found a security bug in gtk+. It would appear to pull arbitrary 32-bit integers out of a .ico file and pass them to malloc().

This can be seen from this portion of the stack trace:

---

#9  0x4147ddf0 in IA__g_try_realloc (mem=<value optimised out>, n_bytes=<value optimised out>) at /build/buildd/glib2.0-2.24.1/glib/gmem.c:225

#10 0xacccb32a in DecodeHeader (data=0xf2bb8a0, buf=0xbf9e0f5c  <incomplete sequence \314>, size=53945, error=0xe562d04) at /build/buildd/gtk+2.0-2.20.1/gdk-pixbuf/io-ico.c:364

---

(Plus correlating with io-ico.c)

There's likely a corrupt icon file on your system somewhere.

Maybe this is a clue as to where it is:

---

#18 0x4e4b74c5 in _gtk_file_system_volume_render_icon (volume=<value optimised out>, widget=Could not find the frame base for "_gtk_file_system_volume_render_icon".

---

Perhaps one of your volume icons is corrupt? You mention that you can't reproduce this reliably. Maybe it's only when a memory stick is plugged in or CD is mounted, etc.

I'd be inclined to file a bug with gtk+.

Cheers

Chris

Thanks!

--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
   http://groups.google.com/a/chromium.org/group/chromium-dev

[DrK]

You are right, I have located the problem.
The crash occurs when I have my external USB disk plugged in the
machine; a FAT32 partition on the driver contains an Autorun.inf file
which loads an .ico from the disk.

A couple of strange things are happening here though:

- The .ico is not corrupt itself, IrfanView is able to show it and in
Windows it also works
- Chromium/Google Chrome both crash, even when going in the Options
menu (not sure why, I suppose some of the "get drive icon" logic is
triggered when the dialog is created)
- Other applications using the GTK file save/open dialog do not crash,
e.g. gedit, transmission, totem. The icon doesn't appear either, but
strace shows the application is opening the .ico file. So I figure
Chromium is doing something different here.

I uploaded the .ico here

http://www.4shared.com/file/8s2nl_HT/usb.html

md5sum = e97af13f579435fed9a44062a7c55931 (sorry for the hosting,
it's something I found in a hurry).

[Evan Martin]

On Thu, Aug 5, 2010 at 1:26 AM, Chris Evans <cev...@chromium.org> wrote:
> Nice. Looks like you've found a security bug in gtk+. It would appear to
> pull arbitrary 32-bit integers out of a .ico file and pass them to malloc().
> This can be seen from this portion of the stack trace:

Source here:
http://git.gnome.org/browse/gdk-pixbuf/tree/gdk-pixbuf/io-ico.c

Relevant code at L237:
if (State->HeaderSize>State->BytesInHeaderBuf) {
guchar *tmp=g_try_realloc(State->HeaderBuf,State->HeaderSize);
if (!tmp) {
g_set_error_literal (error,
GDK_PIXBUF_ERROR,

GDK_PIXBUF_ERROR_INSUFFICIENT_MEMORY,
_("Not enough memory to
load icon"));
return;
}

I think the problem is not a security bug, but rather that GDK is
doing a "try a malloc call but give me NULL when it fails because I
check for that", but we've mapped it to tcmalloc's "alloc or crash the
program".

It appears that glib will let override both its normal malloc (which
it also does crash-by-default) and it's "try malloc" separately:
static GMemVTable glib_mem_vtable = {
standard_malloc,
standard_realloc,
standard_free,
standard_calloc,
standard_try_malloc,
standard_try_realloc,
};

I put all of the relevant info on
http://code.google.com/p/chromium/issues/detail?id=51286

PS: I kind of thing we should only use tcmalloc for renderer
processes. tcmalloc in the browser process has been nothing but pain
-- I even had to write a patch recently to work around a bad
interaction with an nvidia driver!