Comment #41 on issue 32461 by phajdan...@chromium.org: SIGBUS in shared
memory related places, crash on memset
http://code.google.com/p/chromium/issues/detail?id=32461
Okay, so this is the bt full from catherine's core file:
#0 0x00007fbe9788be47 in memset () from /lib/libc.so.6
No symbol table info available.
#1 0x00000000006f863a in Pickle::size (this=0x27260b0, script_dir=<value
optimized out>,
lone_script=...) at /usr/include/bits/string3.h:52
No locals.
#2 Serialize (this=0x27260b0, script_dir=<value optimized out>,
lone_script=...)
at chrome/browser/extensions/user_script_master.cc:252
pickle = {_vptr.Pickle = 0x16b7d50, static kPayloadUnit = 64,
header_ = 0x7fbe8c000ab0, header_size_ = 4, capacity_ = 64,
variable_buffer_offset_ = 0}
#3 UserScriptMaster::ScriptReloader::RunScan (this=0x27260b0,
script_dir=<value optimized out>, lone_script=...)
at chrome/browser/extensions/user_script_master.cc:278
scripts = {<std::_Vector_base<UserScript,
std::allocator<UserScript> >> = {
_M_impl = {<std::allocator<UserScript>> =
{<__gnu_cxx::new_allocator<UserScript>> = {<No data fields>}, <No data
fields>}, _M_start
= 0x0, _M_finish = 0x0,
_M_end_of_storage = 0x0}}, <No data fields>}
__FUNCTION__ = "RunScan"
#4 0x00000000006f4fd8 in
DispatchToMethod<UserScriptMaster::ScriptReloader, void
(UserScriptMaster::ScriptReloader::*)(FilePath, UserScriptList), FilePath,
std::vector<UserScript, std::allocator<UserScript> > > (this=0x2725ff0) at
./base/tuple.h:429
No locals.
Please note that in this case it crashed in UserScriptMaster and not
VisitedLinkMaster.
The memset call from Pickle::size() doesn't make sense to me. header_ seems
to be a valid
pointer, and header_->payload_size is 8. An interesting thing to note
however is that
UserScriptMaster::Serialize uses shared memory.
--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings
Ok, I'm sorry. My errors were related to the end of free disk space on my
home
directory.
After removing some downloads, everything works like a charm now.
Best regards,
Davide
Here's a maybe useful point: SIGBUS is triggered if the underlying file is
truncated.
Comment #44 on issue 32461 by a...@chromium.org: SIGBUS in shared memory
related places, crash on memset
http://code.google.com/p/chromium/issues/detail?id=32461
We've concluded that we don't know what's going on here and we can't repo.
It might be that you're running out of disk space, but it seems unlikely
since, from
the strace, the ftruncate is returning ok. Otherwise, I don't know of any
reason that
the memory maps would be triggering a SIGBUS unless the backing filesystem
went away.
"WontFix" is rather undescriptive here. More like "NoIdeaWhatsGoingWrong"
but since
we can't repo, I don't know what else to do. Sorry.
Hi all there,
thanks for having a look at it. As within project and thousends of lines of
code in
different object-files this comes up sometimes. The only idea left is that
looking
for maybe some big difference in handling things like memory in chrome
compared to
other programs. One big difference at this system is this one :
when i look at the compiletimes, thinking at the sayings chrome is fast and
slim, i
wonder that compared to xulrunner+firefox this takes 50% more time. For me
that aims
to a different style of programming or a program based on another with glued
additionals, not written from scratch.
I am just doing some little perl/java/sql programming but i am aware of a
healthy
working system and spending a lot of time for keeping it clean, without any
unneded
or orphaned stuff on the softside. Hardware is all good brands and i hate
to run in
troubles with that. So what i can say - this system is in a proper state
and with
around 6 hours a day working with that i should have mentioned some related
problems
with other software. This is definetly not the case.
This is not blaming you or chrome, just suggesting to keep that in mind
when looking
at other bugs close to that one.
So again, thanks for spendig your time and i will try newer versions again
sometime.
Karl
I am able to reproduce this on a kubuntu 9.04 32-bit using google chrome
and chromium
from daily ppa.
I made sure none of the known causes are effective on my side. I don't have
my home
on NFS, home has 6+GB free space, /dev/shm is mounted rw, system is being
maintained
in a good way and is considered clean and it's running extremely stable and
reliable.
No corresponding entries in dmesg and /var/log/messages.
I will happily assist getting a grip on that bug. If you want, please just
tell me
what debug output you need and I will do my best to get it to you.
Daniel
As a sidenote, I am using the ubuntu PPA xorg-edgers to have the latest
intel video
drivers. The affected machine is runnning on GM965 graphics chipset. This
is maybe
the biggest difference to my other machines where chrom[e|ium] is running
stable, as
these are running nvidia graphics (closed source driver)
@daniel.eckl: We believe that this is caused by a truncated, mmapped file.
We would need to crashing location memory address that caused the SIGBUS.
(The
location would have to be in the form of a file and line number, preferably
with the
output of gdb's 'disassemble' after 'set disassembly-flavor intel'). I
assume that
the PPA has debuginfo packages that would give you the symbols.
Then, once the processes has crashed, the contents of /proc/<pid>/maps
(where PID is
the browser process PID) would give the VMA which contained the file and
hopefully
the filename. If it crashes in the same place every time, then watching
strace might
show what's going wrong. (Are we truncating to the wrong size, or truncating
afterwards?)
I have a "chromium-browser-dbg" package. I guess that's what I need to
install. But I
am afraid I need easier instructions for creating the dump. Perhaps there
is some
howto around I can follow?
I guess I need to do this:
start "gdb chromium-browser", then setting "set disassembly-flavor intel"
then "run"
and when it crashes, I do a "bt full" and then look into /proc/<pid>/maps
for some file?
I found out that the easiest ways to start chromium in gdb is using the
--debug
command line option. This way I got a full backtrace, but I struggle with
the
disassemble thing. I think need to give the memory location as argument,
but I don't
know how I find out which is the address.
BT attached
Attachments:
bt_full.txt 17.3 KB
I found the cause. The backtrace led me to it. There I saw
~/.mozilla/plugins showing
up and I moved the whole dir to plugins.bak and everything went stable
again.
Then I went there and looked through the files located there. I recognised
a file
named "libflashplayer.so.part" and I don't have any clue how it came there.
I guess I once unpacked the flash plugin with a graphical tool and for any
reason it
did not finish, leaving the partial file behind.
Removing this file and moving the folder back in it's location fixed the
problem.
Program received signal SIGPIPE, Broken pipe.
#0 0xf5777430 in __kernel_vsyscall ()
No symbol table info available.
#1 0xf4c88edb in write () at ../sysdeps/unix/syscall-template.S:82
No locals.
#2 0xf6584a6c in IPC::Channel::ChannelImpl::ProcessOutgoingMessages
(this=0xf8b8f000) at ipc/ipc_channel_posix.cc:859
__eintr_result__ = <value optimised out>
msg = <value optimised out>
amt_to_write = 20
buf
= "\344\276H\370\274\276H\370-\363q\321.\001\000\000\340{+\370\000\000\000\000-\363q",
<incomplete sequence \321>
bytes_written = <value optimised out>
fd_written = -32
out_bytes = 0xf90485c0 ""
msgh = {msg_name = 0x0, msg_namelen = 0, msg_iov = 0xf07aef24,
msg_iovlen = 1, msg_control = 0x0, msg_controllen = 0, msg_flags = 0}
iov = {iov_base = 0xf90485c0, iov_len = 20}
#3 0xf6586a3c in IPC::ChannelProxy::Context::OnSendMessage
(this=0xf8505c80, message=0xf9128ba0) at ipc/ipc_channel_proxy.cc:158
No locals.
#4 0xf6586a72 in IPC::SendTask::Run (this=0xf8e18690) at
ipc/ipc_channel_proxy.cc:27
No locals.
#5 0xf5fd0f63 in MessageLoop::RunTask (this=0xf07af1e4, task=0xf8e18690)
at base/message_loop.cc:409
No locals.
#6 0xf5fd246e in MessageLoop::DeferOrRunPendingTask (this=0xf07af1e4,
pending_task=...) at base/message_loop.cc:418
No locals.
#7 0xf5fd273c in MessageLoop::DoWork (this=0xf07af1e4) at
base/message_loop.cc:525
pending_task = {task = 0xf8e18690, delayed_run_time = {static
kMillisecondsPerSecond = 1000,
static kMicrosecondsPerMillisecond = 1000, static
kMicrosecondsPerSecond = 1000000, static kMicrosecondsPerMinute = 60000000,
static kMicrosecondsPerHour = -694967296, static
kMicrosecondsPerDay = 500654080, static kMicrosecondsPerWeek = <optimized
out>,
static kNanosecondsPerMicrosecond = 1000, static
kNanosecondsPerSecond = <optimized out>,
static kWindowsEpochDeltaMicroseconds = 11644473600000000,
static kTimeTToMicrosecondsOffset = 11644473600000000, us_ = 0},
sequence_num = 0, nestable = true}
It's the error or not?
What should I do?
kenorb: this is an old, closed bug. Please don't update it any more.
The backtrace you have is from a SIGPIPE. That shouldn't be fatal. You may
need to configure your gdb to ignore some signals.