chromium-x11 Segmentation fault on IMX6Q

[dirkdatakamp]

Hi!

I'm trying to build cchromium-x11 under yocto 2.7 for the imx6q.

The application unfortunately throws a segmentation fault.

I built with -fuse-ld=gold does not make a difference.

gdb --args chromium-bin --no-sandbox shows: Thread 1 "chromium-bin" received signal SIGSEGV, Segmentation fault. 0x75de2fbe in unw_set_reg () from /usr/lib/libc++abi.so.1

Anyone ideas?

Thanks Dirk

[rakuco]

Do you have a longer backtrace you could share? Are you using libc++ in either the build or in your runtime environment? In general, libc++abi.so shouldn't be part of the regular workflow at all.

[dirkdatakamp]

strace.txt Here is a strace -o trace.txt chromium --no-sandbox. I do not know if it helps.

I have not specified anything to the libc++.. My only customization in the local.conf: LICENSE_FLAGS_WHITELIST = "commercial" GN_ARGS_append_pn-chromium-x11 = " use_gold=true" DISTRO_FEATURES_append_pn-chromium-x11 = " ld-is-gold"

[rakuco]

Sorry for the false alarm, libc++abi.so and libc++.so are being pulled in by meta-clang.

The strace output doesn't help much, what matters is how unw_set_reg() is being called in the first place.

Does Chromium crash immediately upon launching or is it triggered by some action you perform on the browser? Does running the binary as non-root help in any way?

[dirkdatakamp]

It crashes immediately before anything can be seen on the screen. Same behavior as non-root.

Without export DISPLAY=:0 no segfault an the expected error message: (chromium:447): Gtk-WARNING **: 11:15:57.221: cannot open display:

On the same hardware, Chromium 46 runs under yocto 1.8 withoutproblems for years. But i have to update.

[dirkdatakamp]

I found a similar problem: https://www.bountysource.com/issues/52027380-upgrade-to-chromium-62 "The bug only happens when calling libunwind, e.g. when we want to print current stack trace, I have disabled the stack trace dumping code, which should have worked around the crash. " ... But I do not know how I could try it.

[rakuco]

Hmm, if this is an ARM-specific issue it may be more difficult for me to test personally, as I don't have any hardware to test this on. @kraj does this ring any bells to you?

@dirkdatakamp one thing we can do to rule some of it out is to try using the following in conf/local.conf to avoid building and depending on libc++ (I haven't tried it out yet):

COMPILER_RT_pn-chromium-x11 = ""
LIBCPLUSPLUS_pn-chromium-x11 = ""

[dirkdatakamp]

Thanks @rakuco I will try it overnight.

The problem seems to apply only to ARM32 and ARM64 is ok: https://github.com/OSSystems/meta-browser/issues/299 https://github.com/agherzan/meta-raspberrypi/issues/467

[kraj]

Yeah defaults are to use compiler-rt and libc++ and llvm libunwind. Can you check which libunwind is being used ?

[dirkdatakamp]

with COMPILER_RT_pn-chromium-x11 = "" LIBCPLUSPLUS_pn-chromium-x11 = "" chromium compiled and runs fine.

In poky/meta libunwind is Version 1.3.1, but with many patches like "backtrace-use-only-wth-glibc-and-uclibc"

But i think compiler-rt uses libunwind.a from libcxx with help of 2 patches .

[rakuco]

Thanks for testing, and I'm glad we at least found a workaround. I still need to find some time to properly deal with this though.

@msisov have you experienced this with chromium-ozone-wayland? I think you've tested Chromium on ARM a lot more than I have.

[kraj]

with COMPILER_RT_pn-chromium-x11 = "" LIBCPLUSPLUS_pn-chromium-x11 = "" chromium compiled and runs fine.

In poky/meta libunwind is Version 1.3.1, but with many patches like "backtrace-use-only-wth-glibc-and-uclibc"

these patches are to accomodate musl. Shouldn't be effective here.

But i think compiler-rt uses libunwind.a from libcxx with help of 2 patches .

We are also generating libunwind.so from libcxx. So if you can find that the problem happens with llvm provided libunwind.so at runtime, that will help in pin pointing the problem further.

[kraj]

https://github.com/OSSystems/meta-browser/pull/305 should help here. I am still looking to root cause the crash

[kraj]

another workaround for now is to launch chromium e.g.

LD_PRELOAD=/lib/libgcc_s.so.1 /usr/bin/chromium --no-sandbox

I think this we are missing a link step, I will get to that but meanwhile use this

[kraj]

@dirkdatakamp this should now be fixed with the latest meta-clang layer ( master/warrior/thud ) whichever you are using please update to the tip of that branch and retry also report back the results you get. 

[dirkdatakamp]

The updated 77.0.3865.90 didn't work for me :-(

The browser can not display any page. There are no error messages in the console. --disable-gpu option makes no difference.

[kraj]

This seems to be a different issue then the original segmentation fault that this issue was reporting of so I would say open another ticket for this problem