Chromium segmentation fault on start.

475 views
Skip to first unread message

chrome.gfx

unread,
May 10, 2012, 5:17:51 PM5/10/12
to Chromium-dev


The chromium souce code version is r135761 (SVN revision)

I cross-compiled the source code by using the recipe 3 from
http://code.google.com/p/chromium/wiki/LinuxChromiumArm. The build was
success, and I copied the binaries to the arm platform. The
segmentation fault was observed when I lauched the browser. No
message was printed out on the terminal.

The environments for this testing:
================================
Ubuntu Linaro 11.10 for arm
Kernel version: 3.0.1

GYP_DEFINE
readonly GYP_DEFINES="\
target_arch=arm \
armv7=1 \
sysroot=${SYSROOT} \
remoting=0 \
linux_breakpad=0 \
disable_nacl_untrusted=1 \
linux_use_tcmalloc=0
"


=================================


Any suggestions on how to resolve this issue would be greatly
appreciated.


Lei Zhang

unread,
May 10, 2012, 5:24:39 PM5/10/12
to chrome....@gmail.com, Chromium-dev
Have you tried debugging your Chromium binary with gdb?
> --
> Chromium Developers mailing list: chromi...@chromium.org
> View archives, change email options, or unsubscribe:
>    http://groups.google.com/a/chromium.org/group/chromium-dev

chrome.gfx

unread,
May 10, 2012, 5:51:30 PM5/10/12
to Chromium-dev, chrome....@gmail.com
Yes, I did gdb, but it did not provide much info.

The backtrack I got from gdb is shown as
===========================================
Program terminated with signal 11, Segmentation fault.
#0 0x0020f02c in ?? ()
(gdb)
(gdb) bt
#0 0x0020f02c in ?? ()
#1 0x415decfe in __libc_csu_init ()
#2 0x4ad7fbf8 in __libc_start_main () from /lib/arm-linux-gnueabi/
libc.so.6
#3 0x402a8d44 in _start ()
(gdb)
==========================================
> > Chromium Developers mailing list: chromium-...@chromium.org

chrome.gfx

unread,
May 11, 2012, 10:35:06 AM5/11/12
to Chromium-dev, chrome....@gmail.com
I also compiled the same source code inside the chroot setting for arm
platform. As opposed to the SVN revision number r135761, the
correspondent git commit number is
db897a0054079a125d89a554c1572fc67ab3321a.

The GYP_defines variables used are
======================================
* system_libdir=lib
* pkg-config=pkg-config-arm-generic
* use_xi2_mt=2
* swig_defines=-DOS_CHROMEOS
* chromeos=1
* use_ibus=1
* target_arch=arm
* armv7=1
* v8_can_use_unaligned_accesses=true
* remoting=1
* remove_webcore_debug_symbols=1
* order_text_section=/var/cache/distfiles/target/chrome-src/pgo/
section-ordering-files/orderfile
* strip_tests=1
* use_aura=1
* linux_use_tcmalloc=0
* use_cras=1
* internal_pdf=0
* release_extra_cflags='-g'
======================================

This time the segmentation fault went away and browser can start up
without issues, but it is very very slow. The last chrome binary we
were running was compiled based on source code on 02/16/2012 and its
revision number was r122348. That binary did not have arua_root and
its responsiveness is reasonably well. We think the aura_root may
slow down the browser and want to disable the aura.

However, when I tried to disable aura_root by setting use_aura=0; the
build failed at build/gyp_chromium. Do I have any way to disable aura
inside chroot?

Thank you for the help.

Shaobo

Fred Akalin

unread,
May 11, 2012, 1:30:54 PM5/11/12
to chrome....@gmail.com, Chromium-dev
Just a sanity check, but are you compiling in release mode?  (It's not obvious from the GYP defines)

Chromium Developers mailing list: chromi...@chromium.org

chrome.gfx

unread,
May 11, 2012, 2:07:21 PM5/11/12
to Chromium-dev
yes, the code is compiled in the release mode.

On May 11, 1:30 pm, Fred Akalin <aka...@chromium.org> wrote:
> Just a sanity check, but are you compiling in release mode?  (It's not
> obvious from the GYP defines)
>

Micah Catlin

unread,
May 11, 2012, 4:33:42 PM5/11/12
to chrome....@gmail.com, Chromium-dev
In the long term, new features in Chromium are likely to depend on
some part of Aura for correct operation. So it's probably worth
investing time in discovering how to improve the performance with
Aura, rather than trying to turn it off.

Even if you are successful in building Chromium without Aura today, it
will probably cause problems in the future as everyone else will be
building with it enabled.

Does it seems like the performance regressions you are seeing are
related to increased use of the GPU in Aura? Maybe the target
platform is using software-based GL like Mesa, and it could be
hardware accelerated.
> Chromium Developers mailing list: chromi...@chromium.org

chrome.gfx

unread,
May 14, 2012, 2:25:40 PM5/14/12
to Chromium-dev
Thank you for the information.

working under the platform of arm-ubuntu, we used to launch the chrome
browser with --use-gl=egl and the browser worked fine with software
egl path.

For the build with aura, however, if we passed in the command line
parameter --use-gl=egl, the browser process got stuck and we could
not get a browser window. ps command shows that
==============================================
linaro 6738 56.6 8.5 329140 86848 pts/0 Sl+ 18:09 3:40 /mnt/
chrome/Debug3/chrome --no-sandbox --use-gl=egl
linaro 6739 0.0 0.6 80976 6652 pts/0 S+ 18:09 0:00 /mnt/
chrome/Debug3/chrome --no-sandbox --use-gl=egl
linaro 6740 0.0 1.4 94496 15140 pts/0 S+ 18:09 0:00 /mnt/
chrome/Debug3/chrome --type=zygote
linaro 6752 0.0 0.1 1056744 1768 pts/0 S+ 18:09 0:00 /mnt/
chrome/Debug3/nacl_helper_bootstrap /mnt/chrome_sharedlib_standalone/
Debug3/nacl_helper --at-zero --r_debug=0x000000
linaro 6759 0.2 2.2 139496 22932 pts/0 Sl+ 18:09 0:01 /mnt/
chrome/Debug3/chrome --type=renderer --no-sandbox --use-gl=egl --
disable-databases --lang=en-US --force-fieldtrials1
linaro 6763 0.1 2.1 137792 22064 pts/0 Sl+ 18:09 0:00 /mnt/
chrome/Debug3/chrome --type=gpu-process --channel=6738.1.118741302 --
no-sandbox --use-gl=egl

===============================================

We also got an error message "libEGL warning: DRI2: failed to
authenticate" from the terminal.

Has the software libEGL support in chrome browser been removed from
aura?


Thank you.

Antoine Labour

unread,
May 14, 2012, 2:30:39 PM5/14/12
to chrome....@gmail.com, Chromium-dev
Not specifically. There's no option either way to support or disable a software implementation of libEGL.

Antoine

Chromium Developers mailing list: chromi...@chromium.org
Reply all
Reply to author
Forward
0 new messages