Build chromium on Windows 10

[Frédérik Labbé]

I have gone through all sort of trouble setupping a build on Windows 10, following the instructions. Once being able to make it compile and run successfully, weird behavior occurs (like kilometer long errors then pages not showing up anymore). This behavior only appears in debug mode, though. Release mode is fine, but obviously without symbols it's harder to debug.

Is it possible that the build on windows is having some issue? Have you guys been able to make it work or the platform of choice here is Linux?

Thanks!

[ราชับ เรียบไธสงค]

เมื่อ วันอาทิตย์ที่ 14 สิงหาคม ค.ศ. 2016 9 นาฬิกา 58 นาที 31 วินาที UTC+7, Frédérik Labbé เขียนว่า:

[ราชับ เรียบไธสงค]

เมื่อ วันอาทิตย์ที่ 14 สิงหาคม ค.ศ. 2016 9 นาฬิกา 58 นาที 31 วินาที UTC+7, Frédérik Labbé เขียนว่า:

[Daniel Cheng]

I build Chromium on a Windows 10 machine, and haven't had issues with debug or release builds. What are the errors you're seeing? It sounds like it happens when you try to run the compiled debug copy of Chromium, or is it happening during the build process itself?

Daniel

On Sun, Aug 14, 2016, 12:58 AM Frédérik Labbé <frederi...@gmail.com> wrote:

Sorry. How can a translate help at all?

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

[Frédérik Labbé]

Hi, no errors are happening during the build process. This is the errors I get, along with the steps I used to build:

http://superuser.com/questions/1105560/windows-chromium-browser-fresh-build-stacktrace-and-anonymous-fatal-errors-on-ru

What I mean by debug mode is when you don't configure the build with `gn args` so it will generate debug symbols and everything needed for debugging. However, configuring it otherwise:

• is_debug = false
  
• symbol_level = 0
  
• enable_nacl = false
  
• remove_webcore_debug_symbols = true
  

will make everything work fine.

[Frédérik Labbé]

And yes, this is exactly what you said. I currently have a Debug and Release version of Chromium and the Debug version is the one that has mentioned problems (see: link in the other message).

On Sunday, August 14, 2016 at 4:26:53 AM UTC-4, Daniel Cheng wrote:

[Scott Graham]

It looks like you've just hit a bug to me, though it's not clear what the problem is to me from the stack traces.

You might want to try --user-data-dir=c:\some\temp\dir to see if there's something left over in a profile that's causing problems.

[Lucas Gadani]

Looking at your callstack, it seems that you have some blacklisted module that's being injected into chromium and chromium tries to unload it but fails. It's likely to be malware or some bad behaving anti-virus.

[Frédérik Labbé]

This is interesting. Could it be related to an unpacked plugin I run in Chrome (my own plugin that does nothing evil on its own) ? I sure can try to disable my antivirus and firewall to see if it goes any better.

Also, it seems to occur only while debugging, as building in release mode doesn't show any error. Or maybe the DCHECK throws the stacktrace only when running a debug version? Sorry for newbie questions.

[Frédérik Labbé]

Thank you, I will try that! It sure can help to have a new area to check.

[Peter Kasting]

On Mon, Aug 15, 2016 at 3:28 PM, Frédérik Labbé <frederi...@gmail.com> wrote:

Also, it seems to occur only while debugging, as building in release mode doesn't show any error. Or maybe the DCHECK throws the stacktrace only when running a debug version? Sorry for newbie questions.

DCHECK is a debug-only assertion, so it's a no-op in a release build.

DCHECK failure is a bug; we should never fail a DCHECK, even in exceptional cases.  So whatever is causing this should be found and fixed.

PK

[Frédérik Labbé]

I tried disabling my AV and firewall completely then disabled all my extensions just in case.

I also launched it with a custom `--user-data-dir` to see if it helps.

Issues are still there. I think that the way to go now is to dig into what are the modules that fail this check, how they were loaded and when they are supposed to be unloaded. The fact that the browser eventually becomes unresponsive is telling me that some checks are failing silently afterwards. It is very consistent and stable for me in release mode. Is it a possibility that poor performances on my config breaks something in the sequence that prevents components from responding well in debug mode? This fall I'm gonna invest into more firepower, but now I am expecting it to work at least consistently in slow-motion.

Any idea what could explain it to break without given that much information?

[Frédérik Labbé]

It also feels like more modules are loaded in debug than in release. Ironically, if there actually is some differences in loaded modules I would be much suspicious on what they change in the equation. I could try to force the code into telling more information about what's going on wrong, but that tries and errors are taking some time to build. Any idea or hypothesis on that is greatly appreciated. Thanks :)

[Bruce]

> Also, it seems to occur only while debugging, as building in release mode doesn't show any error.

It is important to understand that "while debugging" is completely orthogonal to "building in release mode". That is, you can do a debug build and then launch it with or without debugging, and you can do a release build and then launch it with or without debugging.

As Peter said, DCHECKs are associated with debug builds - they are debug-build only checks. That is why you are getting no error in release builds.

Have you tried running the debug build under a debugger in order to get more information about what is going wrong? When the first failure is hit you should look at the call stack, local variables, etc., in order to figure out what module is failing to unload.

When investigating in the debugger you should focus on the first DCHECK. Any subsequent failures may be caused by the first one so you should understand and resolve the first issue (which is probably caused by something going wrong even earlier) and not try proceeding past the DCHECK.

When you run a release build the DCHECKs are compiled out which means that you are proceeding past known-bad-state, so unpredictable behavior is not surprising. Stick to the debug builds, under the debugger.

Note that debug builds now default (IIRC) to being component builds which means that many more modules are loaded, by design.

Also, call stacks in text form are more useful than screen shots of call stacks - they are searchable.

[Frédérik Labbé]

It all makes sense. I did not try to run it through the debugger in order to truly investigate in the stack, since the number of file hits and symbols is extremely unpleasant for a HDD in Visual Studio with sub-optimal RAM specs.

I will soon upgrade parts of my config to better handle that kind of projects, then be able to debug it through and come back with more, hopefully with an explanation and a fix. Thanks for the hints guys, the big picture helps a lot.

[haiyan gong]

hi,I also have the trouble in debug mode ,also I use vs for debugging,but not sloved, how did you sloved it ?

VERY THANKS.

在 2016年8月21日星期日 UTC+8下午9:25:48，Frédérik Labbé写道：

[Bruce Dawson]

I would recommend starting a new thread as your issue seems unrelated to this thread. I would also strongly recommend pasting in the text of the call stack you are seeing instead of a bitmap. That makes your question accessible, and searchable.

You are hitting a CHECK failure - something that should always be true is not. In order to help you we will need to know your build settings, runtime environment, and what you have done to try to debug this failure - walking up the stack and looking at the CHECK statement is a good first start.

--

--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---

You received this message because you are subscribed to a topic in the Google Groups "Chromium-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/chromium-dev/BDCz_MqHFi4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to chromium-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/c4da43ea-ca47-4a52-bbd6-0523bfe109e9%40chromium.org.