Chromium

Can you navigate to chrome://crashes and update us the Crash ID recorded for above instance ?

[Comment Deleted]

I did try to look, but it appears that crashes is not enabled in chromium builds.

Here is the concerning part of this. At this point it seems that I can visit a website that fires off some javascript (I'm guessing) that makes my browser dump core. This still isn't even a compatibility issue with OpenBSD usb, or the yubikey u2f token or anything. After my attempt to build chromium with debugging symbols, I learned that even though you can build it with them enabled, it is not practically possible to run it. Where do we go from here?

I'll be opening a separate bug report for this, but it's perhaps worth noting here that the results are identical on FreeBSD.

Unless you suspect the root causes are / fixes will be distinct, a separate bug report doesn't seem necessary.

I agree completely, a separate bug report seems redundant. Thanks for your help!

yourcomputerpal: It should be possible to run a Debug build of Chromium, and I do that on Linux from time to time.  It's possible something's not working with OpenBSD though.

It might be appropriate to create a new bug to track Debug builds not working on OpenBSD, which would be a rather blocking issue for figuring out why Chromium's crashing. :-/

(Unfortunately, I'm in Tokyo for the next three weeks, so I don't have ready access to any of my OpenBSD workstations.)

[Empty comment from Monorail migration]

After several attempts, I am unable to get chromium up and running with the debugging symbols enabled. My limited resources are exhausted and I am turning it over to the chrome team for further investigation. Thanks.

The following stack dump looks strange.
OpenBSD 5.7 GENERIC.MP#881 amd64
Chrome:Version 40.0.2214.115 (64-bit)

% gdb /usr/local/chrome/chrome chrome.core
...
Loaded symbols for /usr/local/lib/libnssckbi.so.36.0
#0  0x00000d0d4420705f in std::_Rb_tree<unsigned long long, std::pair<unsigned long long const, unsigned long long>, std::_Select1st<std::pair<unsigned long long const, unsigned long long> >, std::less<unsigned long long>, std::allocator<std::pair<unsigned long long const, unsigned long long> > >::_M_erase ()
   from /usr/local/chrome/chrome
(gdb) where
#0  0x00000d0d4420705f in std::_Rb_tree<unsigned long long, std::pair<unsigned long long const, unsigned long long>, std::_Select1st<std::pair<unsigned long long const, unsigned long long> >, std::less<unsigned long long>, std::allocator<std::pair<unsigned long long const, unsigned long long> > >::_M_erase ()
   from /usr/local/chrome/chrome
#1  0x00000d0d44206c3f in std::_Rb_tree<unsigned long long, std::pair<unsigned long long const, unsigned long long>, std::_Select1st<std::pair<unsigned long long const, unsigned long long> >, std::less<unsigned long long>, std::allocator<std::pair<unsigned long long const, unsigned long long> > >::_M_erase ()
   from /usr/local/chrome/chrome
#2  0x00000d0d442023e6 in std::_Rb_tree<unsigned long long, std::pair<unsigned long long const, unsigned long long>, std::_Select1st<std::pair<unsigned long long const, unsigned long long> >, std::less<unsigned long long>, std::allocator<std::pair<unsigned long long const, unsigned long long> > >::_M_erase ()
   from /usr/local/chrome/chrome
#3  0x00000d0d404bd3f4 in std::_Rb_tree<pthread*, std::pair<pthread* const, std::string*>, std::_Select1st<std::pair<pthread* const, std::string*> >, std::less<pthread*>, std::allocator<std::pair<pthread* const, std::string*> > >::_M_erase ()
   from /usr/local/chrome/chrome
#4  0x00000d0d40473e48 in std::operator<< () from /usr/local/chrome/chrome
#5  0x00000d0d4047462a in std::operator<< () from /usr/local/chrome/chrome
#6  0x00000d0d40440fa9 in std::vector<__gnu_cxx::_Hashtable_node<std::pair<std::string const, double> >*, std::allocator<__gnu_cxx::_Hashtable_node<std::pair<std::string const, double> >*> >::_M_fill_insert () from /usr/local/chrome/chrome
#7  0x00000d0d4048606e in std::vector<std::pair<unsigned int, int>, std::allocator<std::pair<unsigned int, int> > >::_M_insert_aux ()
   from /usr/local/chrome/chrome
#8  0x00000d0d404734c8 in std::operator<< () from /usr/local/chrome/chrome
#9  0x00000d0d426f2236 in std::deque<long long, std::allocator<long long> >::_M_new_elements_at_front () from /usr/local/chrome/chrome
#10 0x00000d0d426f2645 in std::deque<long long, std::allocator<long long> >::_M_new_elements_at_front () from /usr/local/chrome/chrome
#11 0x00000d0d404a4e0b in std::string::_M_replace_dispatch<wchar_t const*> ()
   from /usr/local/chrome/chrome
#12 0x00000d0d4049fa1b in std::string::_M_replace_dispatch<wchar_t const*> ()
   from /usr/local/chrome/chrome
#13 0x00000d0fc3aad98e in _rthread_start (v=Variable "v" is not available.
)
    at /usr/src/lib/librthread/rthread.c:145
#14 0x00000d0f7a8ef56b in __tfork_thread ()
    at /usr/src/lib/libc/arch/amd64/sys/tfork_thread.S:75
#15 0x0000000000000000 in ?? ()

Neither OpenBSD nor FreeBSD are supported platforms for Chromium.

> Neither OpenBSD nor FreeBSD are supported platforms for Chromium.

Ok. Can you please give us a hint where/how to correctly disable u2f support (in the source code)? U2F is currently clearly not supported on *BSD so the u2f JS API should be disabled.

When API is disabled, the webpage can choose other kind of authentication. It's not the case when the browser crashes...

E.g. when you have two 2-factor authentication means in Google auth (u2f and Google Authenticator), the Google auth chooses u2f as a first mean, the browser crashes and you can't use Authenticator.

I would be interested in this as well. I understand that Linux uses generic HID driver, which is quite minimal, so interfacing with the driver is done in user-space. That means that the BSD's would simply have to enable U2F in Chromium, and have Chromium know how to talk to the HID device. I would be interested in working on this, if its being done.

Same here.  I couldn't even sign in to comment because Google automatically sends me to the U2F page which crashes Chrome.  Had to use Firefox to sign in and comment.

I *really* hope FreeBSD can become a supported OS because it forces me to choose between using FreeBSD or using Chrome (or disabling U2F to make my account less secure).

me too.
cannot use my YubiKey 4.

FreeBSD 11.0-STABLE #0 r317894
Chromium 58.0.3029.96

[11113:654401536:0507/153207.128061:ERROR:KeyboardEventManager.cpp(427)] Not implemented reached in static bool blink::KeyboardEventManager::currentCapsLockState()
Received signal 11 SEGV_MAPERR 000000000000
#0 0x0000046b133c <unknown>
#1 0x0000046b12f3 <unknown>
#2 0x000807c73994 <unknown>
#3 0x000807c72f6f <unknown>
[end of stack trace]

A couple of years passed and FreeBSD patched the bug in their port: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196754

OpenBSD is still affected. Apparently the root cause is the assertion which doesn't hold unless the platform supplies its version of HidService.
HidService::Create() falls through to return nullptr here:
https://cs.chromium.org/chromium/src/services/device/hid/hid_service.cc?g=0&l=44

Which when returned back to HidManagerImpl::HidManagerImpl() should cause a DCHECK:
https://cs.chromium.org/chromium/src/services/device/hid/hid_manager_impl.cc?l=29&rcl=3b7d32154b4e6ca92a7428965626e660d380da76

Except in release builds DCHECK is removed and so the crash happens a tiny bit later in
 device::HidService::AddObserver(device::HidService::Observer*) ()

The fix should be to either
1) add a dummy no-op implementation OR
2) add a real implementation that works on OpenBSD.

Option #1 is easier and also seems to be possible to submit to Chromium without introducing any platform-specific code. Anybody from the project care to comment?

After seeing the "wontfix" comment (because OpenBSD and FreeBSD are not supported) I'd like google to change the status of chromium from "opensource" to "open to a small club of selected people".

It's not really opensource if you tell people you don't support their OS, nor will you accept changes and patches to support it.

Completely inadequate patch for the OpenBSD ports tree (to avoid losing state).

This issue was migrated from crbug.com/chromium/451248?no_tracker_redirect=1