The TCMalloc error message states that TCMalloc doesn't recognize the region of memory 
being passed to it by free().  In order words, the address passed to free() is not 
managed by TCMalloc.  The most likely cause of this is libGL.so.1 is malloc()'ing 
memory, but the malloc() invoked is not TCMalloc's malloc(), but more likely is libc's 
malloc(), yet the free() invoked is TCMalloc's free().  This most likely indicates 
that libGL is using dlsym() or something to lookup malloc() and invoke it through the 
function pointer.

 Issue 38793  has been merged into this issue.

Lots of plugin crashes related to this -> Top Crasher.

I've also seen: http://crash/reportdetail?reportid=18dd08687b8e17dd
Product, Version 	Chrome_Linux ,  5.0.356.2 
ptype 	plugin
lsb-release 	Ubuntu 9.10 
0xb7871422 	[linux-gate.so 	+ 0x00000422] 	
0xb6a11931 	[libc-2.10.1.so 	+ 0x0002d931] 	
0x0860283b 	[chrome 	- internal_logging.cc:77] 	
TCMalloc_CRASH_internal(bool, char const*, int, char const*, char*)
0x08602907 	[chrome 	- internal_logging.cc:94] 	
TCMalloc_CrashReporter::PrintfAndDie(char const*, ...)
0x085f9c21 	[chrome 	- tcmalloc_linux.cc:371] 	(anonymous 
namespace)::InvalidFree(void*)
0xb7767c9c 	[libX11.so.6.2.0 	+ 0x00038c9c] 	
0xb183ec76 	[fglrx_dri.so 	+ 0x0137ac76] 	
0xb183e779 	[fglrx_dri.so 	+ 0x0137a779] 	
0xb1849e2a 	[fglrx_dri.so 	+ 0x01385e2a] 	
0xb189c478 	[fglrx_dri.so 	+ 0x013d8478] 

and

http://crash/reportdetail?reportid=30d5d067ea1c9350
Product, Version 	Chrome_Linux ,  5.0.356.2 
Uptime 	8875 ms 
ptype 	browser
lsb-release 	openSUSE 11.1 (i586) 

Thread 9 *CRASHED* ( SIGABRT @ 0x0000121a )
0xffffe430 	[linux-gate.so 	+ 0x00000430] 	
0xb681a2c7 	[libc-2.9.so 	+ 0x0002c2c7] 	
0x0860283b 	[chrome 	- internal_logging.cc:77] 	
TCMalloc_CRASH_internal(bool, char const*, int, char const*, char*)
0x08602907 	[chrome 	- internal_logging.cc:94] 	
TCMalloc_CrashReporter::PrintfAndDie(char const*, ...)
0x085f9c21 	[chrome 	- tcmalloc_linux.cc:371] 	(anonymous 
namespace)::InvalidFree(void*)
0xb68cd17e 	[libc-2.9.so 	+ 0x000df17e] 	
0xb68cd1a8 	[libc-2.9.so 	+ 0x000df1a8] 	
0x088f2d72 	[chrome 	- host_resolver_proc.cc:217] 	
net::SystemHostResolverProc(std::string const&, net::AddressFamily, 
net::AddressList*)
0x088ec0b4 	[chrome 	- host_resolver_impl.cc:69] 	
net::ResolveAddrInfo(net::HostResolverProc*, std::string const&, net::AddressFamily, 
net::AddressList*)
0x088ed6a4 	[chrome 	- host_resolver_impl.cc:326] 	
net::HostResolverImpl::Job::DoLookup()
0x093ba9c9 	[chrome 	- worker_pool_linux.cc:77] 	(anonymous 
namespace)::WorkerThread::ThreadMain()
0x0863ef50 	[chrome 	- platform_thread_posix.cc:26] 	ThreadFunc(void*)
0xb6d181b4 	[libpthread-2.9.so 	+ 0x000061b4] 

 Issue 40472  has been merged into this issue.

Lei, how do you feel about not making it a ReleaseBlock-Dev until next week?  I am 
planning on figuring out the next step for this bug once I go back to Mountain View 
(Thursday) and can debug this on a 32-bit Lucid box.  I predict that it won't take me 
long to figure out what's going on, after which I can decide what to do next (1) fix 
somehow or (2) disable TCMalloc.  If this is unacceptable, we can turn TCMalloc off 
for now while I debug it, but I'd like to find other TCMalloc bug reports if there are 
any, so I'd like to leave it on.

The plugin crash rate looks ok. Let's leave tcmalloc enabled.

(Finally found this bug)

Hey guys, we start seeing crashes in O3D plugin after TCmalloc is turned on in 
Chrome recently.

http://code.google.com/p/chromium-os/issues/detail?id=2010

I can 100% repro this. Everytime you start a 2-way video chat, the O3D crashes on 
the second video stream.
I am pretty sure it is related to a new-delete pair in the plugin code. (If I 
disable it, everything works fine.)

If my understanding is correct, this definetely should a Release-Block issue for 
ChromeOS/Chrome. Since GTalk video will not be working at all ....

I hope we can turn tcmalloc off before has a full-understanding on the crashes. 
I can provide more information about the O3D plugin crash if needed.

We won't go to a larger audience (beta or stable) without addressing this.  This crash has been known for a few 
weeks now, so I don't think it'd do much harm to leave it in for another week while I debug it and figure out 
exactly what's going on (as stated before, we're trying to flush out bugs caused by the TCMalloc switch, hence the 
rationale for leaving it on).  Let me know if that would cause any specific problems for you.

Unfortunately I was unable to repro this yesterday.  I will probably need to bug 
zhurunz or someone for help to repro this.  I'll try again Monday.  For now, I'm going 
to disable TCMalloc :(

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=44105 

------------------------------------------------------------------------
r44105 | willchan@chromium.org | 2010-04-09 11:26:27 -0700 (Fri, 09 Apr 2010) | 4 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/build/common.gypi?r1=44105&r2=44104

Turn off TCMalloc for Linux to fix plugin crashes.
BUG= 38692 

Review URL: http://codereview.chromium.org/1617014
------------------------------------------------------------------------

I'm still debugging this, but yes, it looks like a malloc() implementation mismatch.  
Here's a lovely stacktrace:
(gdb) ba
#0  0xb721f620 in sbrk () from /lib/tls/i686/cmov/libc.so.6
#1  0xb71cc0f1 in __default_morecore () from /lib/tls/i686/cmov/libc.so.6
#2  0xb71c8f4d in ?? () from /lib/tls/i686/cmov/libc.so.6
#3  0xb71ca898 in malloc () from /lib/tls/i686/cmov/libc.so.6
#4  0xb71caa13 in malloc () from /lib/tls/i686/cmov/libc.so.6
#5  0xa9a3265c in ?? () from /usr/lib/libGLcore.so.1
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

So yeah, libGLcore.so.1 is using libc's malloc somehow :(  I need to debug further to 
see why.

+evan for flash fun

Looks like flash is dlopen()'ing libGL.so.1 with RTLD_DEEPBIND(0x8)|RTLD_NOW(0x2) = 0xa.  Sad panda :(  This 
causes libGL.so.1 to load its own copy of libc and use its malloc() implementation.  Of course, when you are 
passing malloc()'d memory from libGL to code that wasn't using the same malloc() implementation, and have that 
code call free() on said memory, bad things happen.

Breakpoint 2, 0xb7ea2b00 in dlopen () from /lib/tls/i686/cmov/libdl.so.2
0xbfffafbc:     0xb5a2ea60      0xb622d5a8      0x0000000a      0xbfffafe8
(gdb) p (char*)0xb6222d5a8
warning: value truncated
$55 = 0x6222d5a8 <Address 0x6222d5a8 out of bounds>
(gdb) p (char*)0xb622d5a8
$56 = 0xb622d5a8 "libGL.so.1"
(gdb) ba
#0  0xb7ea2b00 in dlopen () from /lib/tls/i686/cmov/libdl.so.2
#1  0xb5a2ea60 in ?? () from /usr/lib/flashplugin-installer/libflashplayer.so
#2  0xb5a333a5 in ?? () from /usr/lib/flashplugin-installer/libflashplayer.so
#3  0xb5a33b98 in ?? () from /usr/lib/flashplugin-installer/libflashplayer.so
#4  0xb5a1d180 in ?? () from /usr/lib/flashplugin-installer/libflashplayer.so
#5  0xb5a1e3f6 in ?? () from /usr/lib/flashplugin-installer/libflashplayer.so
#6  0xb5a20c17 in ?? () from /usr/lib/flashplugin-installer/libflashplayer.so
#7  0xb5b695bd in ?? () from /usr/lib/flashplugin-installer/libflashplayer.so
#8  0xb5d81158 in ?? () from /usr/lib/flashplugin-installer/libflashplayer.so
#9  0xb5d83b3f in ?? () from /usr/lib/flashplugin-installer/libflashplayer.so
#10 0xb5d4c52e in ?? () from /usr/lib/flashplugin-installer/libflashplayer.so
#11 0xb5c8ac7d in ?? () from /usr/lib/flashplugin-installer/libflashplayer.so
#12 0xb5c95e25 in ?? () from /usr/lib/flashplugin-installer/libflashplayer.so
#13 0xb5d83b5a in ?? () from /usr/lib/flashplugin-installer/libflashplayer.so
#14 0xb5b844e8 in ?? () from /usr/lib/flashplugin-installer/libflashplayer.so
#15 0xb5d81158 in ?? () from /usr/lib/flashplugin-installer/libflashplayer.so
#16 0xb5c94fa5 in ?? () from /usr/lib/flashplugin-installer/libflashplayer.so
#17 0xb5d83b5a in ?? () from /usr/lib/flashplugin-installer/libflashplayer.so
#18 0xb5b844e8 in ?? () from /usr/lib/flashplugin-installer/libflashplayer.so
#19 0xb5d81158 in ?? () from /usr/lib/flashplugin-installer/libflashplayer.so
#20 0xb5c94fa5 in ?? () from /usr/lib/flashplugin-installer/libflashplayer.so
#21 0xb5d83b5a in ?? () from /usr/lib/flashplugin-installer/libflashplayer.so
#22 0xb5c9798e in ?? () from /usr/lib/flashplugin-installer/libflashplayer.so
---Type <return> to continue, or q <return> to quit---
#23 0xb5d9ebe0 in ?? () from /usr/lib/flashplugin-installer/libflashplayer.so
#24 0xb5dac0f6 in ?? () from /usr/lib/flashplugin-installer/libflashplayer.so
#25 0xb5a201cb in ?? () from /usr/lib/flashplugin-installer/libflashplayer.so
#26 0xb7bf6474 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#27 0xb78e9072 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#28 0xb78fe7a8 in ?? () from /usr/lib/libgobject-2.0.so.0
#29 0xb78ff9b8 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
#30 0xb78fffb6 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#31 0xb7d12820 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#32 0xb7beec20 in gtk_propagate_event () from /usr/lib/libgtk-x11-2.0.so.0
#33 0xb7befea9 in gtk_main_do_event () from /usr/lib/libgtk-x11-2.0.so.0
#34 0xb7a7965a in ?? () from /usr/lib/libgdk-x11-2.0.so.0
#35 0xb7854e88 in g_main_context_dispatch () from /lib/libglib-2.0.so.0
#36 0xb7858730 in ?? () from /lib/libglib-2.0.so.0
#37 0xb7858863 in g_main_context_iteration () from /lib/libglib-2.0.so.0
#38 0x086976e5 in base::MessagePumpForUI::RunWithDispatcher(base::MessagePump::Delegate*, 
base::MessagePumpForUI::Dispatcher*) (this=0xa4f9f40
)
    at base/message_pump_glib.cc:195
#39 0x08697320 in base::MessagePumpForUI::Run (this=0xa4f9f40, 
    delegate=0xbfffe944) at ./base/message_pump_glib.h:59
#40 0x086775a4 in MessageLoop::RunInternal (this=0xbfffe944)
    at base/message_loop.cc:205
#41 0x086776a6 in MessageLoop::Run (this=0xbfffe944)
---Type <return> to continue, or q <return> to quit---
    at base/message_loop.cc:155
#42 0x093d0a21 in PluginMain (parameters=0xbffff1e4)
    at chrome/plugin/plugin_main.cc:133
#43 0x0806f6ac in ChromeMain (argc=7, argv=0xbffff3d4)
    at chrome/app/chrome_dll_main.cc:722
#44 0x08070a80 in main (argc=-1073744984, argv=0xb7171b56)
    at chrome/app/chrome_exe_main_gtk.cc:47
(gdb)

Would intercepting calls to dlopen help at all? ... i.e. we could strip RTLD_DEEPBIND 
but I'm not sure what other problems that would result in.

Yeah, Markus and I discussed those options.  It's unclear if it'll work.  We really need to talk to the flash guys to 
see why they're doing this.

There is no case in GL where the user mallocs memory and passes it to GL to free it  
(or vice versa).

I chatted with piman offline about this.  Based on what we're seeing, there indeed 
seems to be a case where GL malloc()s the memory and then calls XFree(), which then 
uses TCMalloc, on it.

Flash dont crash here, but in Fullscreen with Flash, like Farmville.com - it lags so 
much its completely useless. It can take almost a minute for flash app to register / 
act on keypresses when in fullscreen mode.

As this bug is about a crash, and not about flash performance issues, I ask you not to 
clutter this bug report with your performance issue.  Please file a new bug.

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=44975 

------------------------------------------------------------------------
r44975 | willchan@chromium.org | 2010-04-19 15:51:11 -0700 (Mon, 19 Apr 2010) | 5 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/third_party/tcmalloc/chromium/src/tcmalloc.cc?r1=44975&r2=44974

Linux: Make TCMalloc override ptmalloc hooks.
Certain libraries still seem to fall through to ptmalloc.  At least one cause seems to be because some libraries dynamically load other libraries via dlopen() invoked with RTLD_DEEPBIND.  Therefore, we override ptmalloc's hooks to pass through to TCMalloc.  This is suboptimal since it adds an extra function call per malloc()/realloc()/free()/memalign() invocation, but it should catch all cases where the library does not correctly allow for malloc implementation overrides.
BUG= 38692 

Review URL: http://codereview.chromium.org/1665005
------------------------------------------------------------------------

TCMalloc is reverted on Mstone 5, so I'm dropped the Mstone-5 label.  This bug is 
fixed on trunk now, although it's possible there's another bug.

 Issue 28820  has been merged into this issue.

Verified, thanks!

Apparently, it also affects the beta channel (5.0.342.9~r43360):

https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/570067

I don't think this can affect the beta channel - tcmalloc is not enabled there. You 
might be running into a different bug?

Thanks for this report.  I'll look into reverting TCMalloc on the beta channel.

Er, I should state that I haven't checked to see if TCMalloc is enabled on beta channel.  So if thestig says it isn't, 
then I'd believe it.

I doublechecked it now and indeed it is disabled in our 342 branch:
http://src.chromium.org/viewvc/chrome/branches/342/src/build/common.gypi?
annotate=40440 (search for linux_use_tcmalloc).

@fta: I recommend doublechecking in your debug package to make sure the TCMalloc 
symbols are not present:


  LINK(target) out/Debug/chrome
willchan@penguin:/usr/local/google/chromium1/src$ nm out/Debug/chrome | grep TCMalloc
0000000000d3b562 t _Z12ExtractStatsP13TCMallocStatsPm
0000000000d472f8 T _Z14TCMalloc_CRASHbPKciS0_z
0000000000d46f5c T _Z16TCMalloc_MESSAGEPKciS0_z
0000000000d4e9a0 T _Z20TCMalloc_SystemAllocmPmm
0000000000d4e5f2 T _Z21TCMalloc_SystemCommitPvm
0000000000d4e7ba T _Z22TCMalloc_SystemReleasePvm
...

Just got this crash as well. Ill star this bug so I can be kept up to date. Im a bit 
unsure how to get the stack traces and such, if those are even needed; this bug has 
quite a lot of info already. If anything more is needed, feel free to ask. :)

This bug should be fixed.  Please post your version (browse to about:version and copy 
and paste everything in there into this bug report).  My suspicion is you're on a 
really old version.  If not, then I'll help you provide us with more debugging info.

Version info pasted below (not that its all that paste friendly). I didnt really 
think about the version since this report is just two months old. I opted for 
installing chromium through the ubuntu package repository, compiling from source 
seemed a bit daunting. Or is it the flashplugin that should be updated? Maybe I 
should take the time to compile it, if the project is moving forward this fast.


Chromium	5.0.342.9 (Developer Build 43360)
WebKit	533.2
V8	2.1.2.7
User Agent	Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/533.2 (KHTML, 
like Gecko) Chrome/5.0.342.9 Safari/533.2
Command Line	 /usr/lib/chromium-browser/chromium-browser 
https://mail.google.com/mail/#inbox

Yes, this version is too old.  You shouldn't need to build chromium yourself.  I'd be surprised if the ubuntu 
package repository didn't have a newer version that isn't buggy.  I'm sure if you ask on the ubuntu forums, fta 
will be able to help.  You could also install Google Chrome which will auto-update itself.  Check out 
www.google.com/chrome to download the beta channel.

https://launchpad.net/~chromium-daily

That page has links to PPA's for the stable, beta, dev channels and daily builds on 
ubuntu. 

Ubuntu Lucid is currently receiving the update (it's the LTS release, so the Ubuntu 
security team is taking extra steps to qualify all the packages being updated there).

All updates for lucid will appear in either the lucid-security or lucid-updates 
repository (via lucid-proposed).

https://launchpad.net/ubuntu/+source/chromium-browser

Just got an update to the chromium browser through synaptic update manager.

Chromium	6.0.408.1 (Developer Build 47574) Ubuntu
WebKit	534.0
V8	2.2.10
User Agent	Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/534.0 (KHTML, 
like Gecko) Chrome/6.0.408.1 Safari/534.0
Command Line	 /usr/lib/chromium-browser/chromium-browser

But the player still crashes when switching to full screen mode. Before being able to 
play the video youtube asked me to update to flash player version 10, which I did 
using a .deb downloaded from Adobe.

Any ideas? Am I still behind in version?

Please refer to https://wiki.ubuntu.com/Chromium/Debugging to get us backtraces of the 
crash.

I followed the instructions on the page and have a trace now. Its attached. Looking 
through it, I see a few interesting lines:

[1769:1769:821540418:ERROR:chrome/browser/tab_contents/tab_contents.cc(1941)] Not 
implemented reached in virtual void TabContents::OnCrashedPlugin(const FilePath&) 
convert plugin path to plugin name

Although, it seems like there is a problem printing the plugin path, I guess that the 
flash plugin has already failed at this point. Just above that I find this line:

(exe:1838): Gdk-WARNING **: XID collision, trouble ahead
Xlib:  extension "GLX" missing on display ":0.0".

Which looks very much likes something that can disrupt the process of getting 
something full screen.

My version is printed two comments above. To clarify, this is when displaying a (any) 
youtube video full screen.

gdb-chromium.txt 26.1 KB View Download

There are a few confusing things about your report.  You claim that the plugin 
process is crashing.  From your backtrace, it looks like a browser process crash (the 
whole browser, not just the flash player).  You also didn't completely follow the 
directions, since it states:
=====
do what you need to do to trigger the crash, then:


(gdb) backtrace
(gdb) thread apply all backtrace
(gdb) quit
=====

I don't see a backtrace in your output.  As far as I can tell, the CertVerifier is 
seg faulting.

Disregard my last comment, I was reading the wrong file :P  Have too many "gdb-
chromium.txt" files from other debugging sessions.

Your gdb session seems to be attached to the browser process instead of the plugin 
process.  The signal handled is a SIGINT, which probably means you pressed ctrl-c to 
get into the debugger.  You need to catch the backtrace for the plugin process.  One 
way to do so is to follow the instructions in 
http://code.google.com/p/chromium/wiki/LinuxDebugging.  If you add --plugin-
launcher='xterm -e gdb --eval-command=run --args' to the gdb "run" command, or use 
"set-args" to set that argument, it'll start up the plugin process in a separate xterm 
that runs gdb, so you can debug it there and get us a backtrace.

With your supplied arguments to 'run' chromium started, and as soon as I navigated to 
youtube.com it popped up a second window (xterm), named "gdb", is this the intended 
behavior? 

I reproduced the bug and got some nice traces. However, I couldnt figure out how to 
copy the output of the xterm window. Nor could I find an argument to run that put it 
in some file. The gdb-chromium.txt file didnt contain much at all. 

But xterm mentioned /usr/lib/adobe-flashplugin/libflashplayer.so several times in the 
stack traces. So its there, I just need to be able to post it. Any hints?

Are you familiar with copy/pasting by highlighting the text and then middle-clicking 
(if you don't have a middle button, usually the system is configured to emulate it 
when you press both the left and right buttons) to paste it?

And yes, that makes sense that libflashplayer.so is in the stacktrace.

If you can't get copy/paste working, you can also try to take a screenshot of the 
xterm output.  Please refer to http://tips.webdesign10.com/how-to-take-a-screenshot-
on-ubuntu-linux to see how to do that.

Yea, I was able to copy parts of the console. But since the xterm window was so small 
I couldnt show all the output at once, in order to copy it. Falling back to a 
screenshot or copying parts of the output and puzzling them together both felt wierd.

I also tried replacing 'xterm' with 'gnome-terminal' in the command, but the gnome 
terminal didnt recognize the --eval-command parameter.

I scrolled through the output to see if I could figure out any parts that were of 
special interest and just copy those. But I couldnt find anything obvious. Although 
the line I pasted before was written again there as well:

Xlib:  extension "GLX" missing on display ":0.0".

You can probably resize the xterm window, but the thread stacktraces will probably 
still overflow.  It's probably ok not to include all the thread stacktraces, so try 
not including the "thread apply all backtrace" command.  What is most important is the 
output of the "backtrace" gdb command.

you can use "xterm -sb -sl 1000 -e gdb ..." (it adds a scrollbar and extends the 
scroll history to 1000 lines)

You can also try with 'script' (xterm -e 'script -f /tmp/crlog.$$ -c gdb ...'  but 
it's tricky to find the right combination of ['"\] to make it work as expected 
depending on the user shell.

This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.