Thanks for the report. Are you about to use src/tools/bisect-builds.py to get a bisect range? This might help us figure out what's going on.

I will try to check build with src/tools/bisect-builds.py as soon as I can

The following version 69.0.3497.0 was correctly started

https://commondatastorage.googleapis.com/chromium-browser-snapshots/index.html?prefix=Win/576753/

And does the next snapshot (https://commondatastorage.googleapis.com/chromium-browser-snapshots/index.html?prefix=Win/576755/) not work?

The following build works
70.0.3525.0
https://commondatastorage.googleapis.com/chromium-browser-snapshots/index.html?prefix=Win/583911/

My build
70.0.3538.77
didn't work

build from 72.0.3605.0
https://download-chromium.appspot.com/
didn't work

build 70.0.3538.0 from 
https://commondatastorage.googleapis.com/chromium-browser-snapshots/index.html?prefix=Win/587814/
didn't work

build 70.0.3525.0 works
https://commondatastorage.googleapis.com/chromium-browser-snapshots/index.html?prefix=Win/583911/

build 70.0.3527.0 didnt't 
https://commondatastorage.googleapis.com/chromium-browser-snapshots/index.html?prefix=Win/584327/

Thanks. That's still a fairly big range. Are you able to use this command to find the narrowest range where the break was introduced:

python tools\bisect-builds.py -a win64 -g 583911 -b 584327 -- --no-first-run

If possible, please paste the output of that command into the bug -- it will hopefully point to a very small number of commits of interest. Thanks very much for your help.

70.0.3526.0 didnt't work
https://commondatastorage.googleapis.com/chromium-browser-snapshots/index.html?prefix=Win/584004/

There is a bisect log, but I didn't trust results, because I suppose it doesn't launch browser from appdata\local folder

C:\depot_tools>python bisect.py -a win -g 583911 -b 584004 -- --no-first-run
Downloading list of known revisions... (use --use-local-cache to cache and re-use the list of revisions)
Downloading revision 583969...in/96338//
Received 130030949 of 130030949 bytes, 100.00%
Bisecting range [583911 (good), 584004 (bad)], roughly 5 steps left.
Trying revision 583969...
Revision 583969 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: g
Downloading revision 583982...
Bisecting range [583969 (good), 584004 (bad)], roughly 4 steps left.
Trying revision 583982...
Revision 583982 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: g
Downloading revision 583991...
Bisecting range [583982 (good), 584004 (bad)], roughly 3 steps left.
Trying revision 583991...
Revision 583991 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: g
Downloading revision 583996...
Bisecting range [583991 (good), 584004 (bad)], roughly 3 steps left.
Trying revision 583996...
Revision 583996 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: g
Downloading revision 583998...
Bisecting range [583996 (good), 584004 (bad)], roughly 2 steps left.
Trying revision 583998...
Revision 583998 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: g
You are probably looking for a change made after 583998 (known good), but no later than 584004 (first known bad).
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/4aa673fc96d50688094c0431bec30675b80983ee..c4b2c0cbbd67f79dcaa29646368a9a5997cd29fe

build 70.0.3525.0 is good
https://commondatastorage.googleapis.com/chromium-browser-snapshots/index.html?prefix=Win/583923/

build 70.0.3526.0 is not
https://commondatastorage.googleapis.com/chromium-browser-snapshots/index.html?prefix=Win/583936/

how I can get commit log from 583923 to 583936?

this is not suitable
https://chromium.googlesource.com/chromium/src/+log/70.0.3525.0..70.0.3526.0?pretty=fuller&n=10000

You could run bisect-builds like this to be sure that it uses a dir within the user's AppData\Local dir:

python tools\bisect-builds.py -a win64 --user-data-dir="%LOCALAPPDATA%\BisectUserData" -g 583911 -b 584327 -- --no-first-run

As for how to look at the change log between two commit positions, I imagine you need to get the commit hash for each position. While there's likely a better way, I usually use https://crrev.com/583923 to get the hash for a position (r583923, in that case).

This might be the range you're looking for:

https://chromium.googlesource.com/chromium/src/+log/b0080a1d0ba739ff3901b1785f64386ace7084f2..3c379ddb0084016c3188cd385c8bd316253b2fdd

pavel.seleznev@ Thanks for the issue.

Unable to test and confirm this issue on Windows 10, as we do not have admin credentials to create a new user on Windows.
As per comment #12, this seems to be a regression in M-70 builds. Hence adding 'TE-NeedsTriageFromHYD' label and requesting Inhouse team to look into the issue and help further.

Thanks..

Good version also contains "eglCreateContext failed with error EGL_BAD_ALLOC" in chrome_debug.log when started with --enable-logging option

username ßtest would be enough to reproduce the problem on OS with russian national settings (suppose in this case - any but not german national settings/lang)

win 7 x64 sp1

Deleted: photo_2018-11-09_16-55-20.jpg 93.1 KB

	photo_2018-11-09_16-55-20.jpg 93.1 KB View Download

In readable format from debug version

---------------------------
Fatal error
---------------------------
[3260:1836:1112/154106.232:FATAL:scoped_refptr.h(219)] Check failed: ptr_. 
Backtrace:
	base::debug::StackTrace::StackTrace [0x5F3BC036+102]
	base::debug::StackTrace::StackTrace [0x5F3BB0DB+27]
	logging::LogMessage::~LogMessage [0x5F4211E4+148]
	gl::InitializeGLContext [0x64059BFF+335]
	gl::GLSurfaceEGL::InitializeOneOffCommon [0x640C6E92+1026]
	gl::GLSurfaceEGL::InitializeOneOff [0x640C6361+97]
	gl::init::InitializeExtensionSettingsOneOffPlatform [0x65F7A131+5793]
	gl::init::InitializeGLOneOffImplementation [0x65F72041+113]
	gl::init::InitializeGLOneOff [0x65F71E20+2352]
	gl::init::InitializeGLNoExtensionsOneOff [0x65F71F98+296]
	gpu::GpuInit::InitializeAndStartSandbox [0x606AF60E+1278]
	content::WebPreferences::operator= [0x0F7526F0+1936]
	content::ContentMain [0x13ACC53F+575]
	content::ContentMain [0x13ACD68A+5002]
	content::ContentMainRunner::ContentMainRunner [0x13AC9DF2+850]
	service_manager::Main [0x02FC3EF3+1811]
	content::ContentMain [0x13ACC35C+92]
	ChromeMain [0x5255132F+495]
	Ordinal0 [0x00D3B9EF+47599]
	Ordinal0 [0x00D31478+5240]
	IsSandboxedProcess [0x00F9247E+2199246]
	IsSandboxedProcess [0x00F925D1+2199585]
	IsSandboxedProcess [0x00F9269D+2199789]
	IsSandboxedProcess [0x00F926A8+2199800]
	BaseThreadInitThunk [0x77C11174+18]
	RtlInitializeExceptionChain [0x77DAB3F5+99]
	RtlInitializeExceptionChain [0x77DAB3C8+54]


---------------------------
ОК   
---------------------------

I have tried to run base_unittest on such account to check command line tests, but it is failed even with substituted temp folder

Also have reviewed commits from 583911 to 584327
https://chromium.googlesource.com/chromium/src/+log/70.0.3525.0..70.0.3526.0?pretty=fuller&n=10000
but didn't found the reason of changed behavior 

That FATAL message is from a DCHECK, so it's either coming from a debug build, or a release build with dcheck_always_on=true in args.gn. I'm not confident that this is related to the original issue, as I don't believe that Chromium snapshots are built with dcheck_always_on. Could you confirm that this error is coming from one of the Chromium snapshot builds?

If it's coming from a local build, perhaps the stack would be more informative if you build with symbol_level=2.

# Adding to comment #21.

Tried to reproduce the issue on Windows 10 as per comment #0 by following the below steps.

1. Tried to create a new user on Windows from Settings -> Other People, with the username 'ßtest', but we are seeing an error as attached in the screen shot.
2. Also tried creating a gmail account with the above username but unable to create as special characters in gmail username field is not being allowed.

pavel.seleznev@ Request you to provide steps/screen cast as how you are creating a new user on windows with strange username.

Thanks.. 

Deleted: 902684-1.png 115 KB

	902684-1.png 115 KB View Download

1) The screenshot above was illustrated the crash that happen only on strange account and didn't on normal account, thow it may be simple DCHECK. (chromium build with debug info). I will check it with symbol_level=2, but it will take some time.

2) I have windows 10 only with russian interface language, but I have just checked that I can successfully create such account 

Deleted: btest user.jpg 191 KB

	btest user.jpg 191 KB View Download

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

pavel.seleznev@ Thanks for the update.

As we are unable to create a user with strange username, adding 'TE-NeedsTriageFromHYD' label and requesting Inhouse team to cross check on localised OS as per comment #23.

Thanks..

Hello,

Good news - I have fixed issue

1) issue happen only on Windows 7, earlier I have thought that Windows 10 also have such crash but it doesn't (I asked my QA department to confirm it on Windows 10, but they have mistaken (I use Windows 7 because it faster)). Therefore, we didn't have issues with creating profiles with strange names on Windows 10 (if you want - I can provide video)

2) To repeat you should use windows 7 (we use clean snapshot of W7 Professional (both x32  and x64) without SP1, but I suppose that SP1 didn't influence for error reproducing

3) crash happen in \src\ui\gl\gl_surface_egl.cc 
in function bool GLSurfaceEGL::InitializeOneOffCommon()

after the following line
    scoped_refptr<GLContext> context = InitializeGLContext(
        new GLContextEGL(nullptr), surface.get(), GLContextAttribs());

you use context

if (!context->MakeCurrent(surface.get()))
  g_egl_surfaceless_context_supported = false;

but in our case the context didn't created due to strange account or some issues with native gl functions 

so I have added check
    if (context.get())
    {

        if (!context->MakeCurrent(surface.get()))
            g_egl_surfaceless_context_supported = false;

and browser has successfully started

piman: it looks like r232615 landed this code causing a startup crash. Would you please triage/fix as appropriate? Thanks.

OK, to avoid the assertion, it's a simple fix. I will land a CL for that shortly after.

However, this isn't some code we touched recently, so I am curious what triggers the behavior change. Specifically, why user name matters.

My first guess would be some Chrome variation. However, unfortunately since the bug is Chrome fails to launch, so we couldn't really take a look at chrome://version/?show-variations-cmd

Ligi, do you have a Win7 bot on your side that you can try to reproduce this? If we could reproduce, I'll debug into the root cause of this.

Assigning to ligi to reproduce

Amit, could you please help in triaging this issue in a Win7 system with admin access by creating strange windows accounts.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/1f068a7da82b2c4a50ae262ac2429a61864bc7de

commit 1f068a7da82b2c4a50ae262ac2429a61864bc7de
Author: Zhenyao Mo <zmo@chromium.org>
Date: Fri Nov 16 01:55:52 2018

Check GL context creation succeeds before using the context.

BUG= 902684 
TEST=bots
R=piman@chromium.org

Change-Id: I0c7267b6c23313e9613d38ecdf399707cbd8b11c
Reviewed-on: https://chromium-review.googlesource.com/c/1338494
Commit-Queue: Zhenyao Mo <zmo@chromium.org>
Reviewed-by: Antoine Labour <piman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#608627}
[modify] https://crrev.com/1f068a7da82b2c4a50ae262ac2429a61864bc7de/ui/gl/gl_surface_egl.cc

Tried to repro this on the chromium build(revision 608609) without fix on 

VMware(russian localized OS- Win7) as well as on Win-7(English OS) by creating a new user 'ßtest'. In both scenarios chromium launched fine without any issues.

pavel.seleznev@: Could you please check the issue on the latest chromium snapshots and confirm whether the issue is resolved from your end.

Deleted: 902684_BeforeFix_English_OS_Win7.png 203 KB

	902684_BeforeFix_English_OS_Win7.png 203 KB View Download

Deleted: 902684_Russian_Win7.png 279 KB

	902684_Russian_Win7.png 279 KB View Download

OK, Thanks for trying.

Since I already landed this CL so Chrome/Chromium could launch fine now, and since we can't reproduce the issue on our side, I am closing this as Fixed. There is still a mystery here, but we don't have the luxury (time wise) to get to the bottom of it.

Just checked that 

build 70.0.3527.0 didnt't work
https://commondatastorage.googleapis.com/chromium-browser-snapshots/index.html?prefix=Win/584327/

And the latest build was started correctly
https://www.chromium.org/getting-involved/download-chromium

so, the bug was fixed

Thank you