[chromium-dev] Build failing due to v8_mkshapshot.exe crash?
I'm trying to build Chrome this morning and v8_mksnapshot.exe is crashing? This is a clean build. Thoughts? -eric --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Build failing due to v8_mkshapshot.exe crash?
Unhandled exception at 0x004413be in v8_mksnapshot.exe: 0xC005:
Access violation reading location 0x2522e72c.
v8_mksnapshot.exe!v8::internal::Invoke(bool construct=true,
v8::internal::Handlev8::internal::JSFunction func={...},
v8::internal::Handlev8::internal::Object receiver={...}, int argc=6,
v8::internal::Object * * * args=0x0012fbb0, bool *
has_pending_exception=0x0012fb83) Line 90 + 0x15 bytesC++
v8_mksnapshot.exe!v8::internal::Execution::Call(v8::internal::Handlev8::internal::JSFunction
func={...}, v8::internal::Handlev8::internal::Object receiver={...},
int argc=6, v8::internal::Object * * * args=0x0012fbb0, bool *
pending_exception=0x0012fb83) Line 116 + 0x25 bytesC++
v8_mksnapshot.exe!v8::internal::MessageHandler::MakeMessageObject(const
char * type=0x00513d68, v8::internal::MessageLocation *
loc=0x0012fc00,
v8::internal::Vectorv8::internal::Handlev8::internal::Object
args={...}, v8::internal::Handlev8::internal::String
stack_trace={...}) Line 110 + 0x25 bytes C++
v8_mksnapshot.exe!v8::internal::Top::DoThrow(v8::internal::Object *
exception=0x01003c00, v8::internal::MessageLocation *
location=0x, const char * message=0x) Line 810 + 0x1c
bytes C++
v8_mksnapshot.exe!v8::internal::Top::Throw(v8::internal::Object *
exception=0x01003cd5, v8::internal::MessageLocation *
location=0x) Line 637 + 0x11 bytes C++
v8_mksnapshot.exe!v8::internal::Runtime_Throw(v8::internal::Arguments
args={...}) Line 3742 + 0x2e bytes C++
v8_mksnapshot.exe!v8::internal::Invoke(bool construct=true,
v8::internal::Handlev8::internal::JSFunction func={...},
v8::internal::Handlev8::internal::Object receiver={...}, int argc=0,
v8::internal::Object * * * args=0x, bool *
has_pending_exception=0x0012fd87) Line 91 C++
v8_mksnapshot.exe!v8::internal::Execution::Call(v8::internal::Handlev8::internal::JSFunction
func={...}, v8::internal::Handlev8::internal::Object receiver={...},
int argc=0, v8::internal::Object * * * args=0x, bool *
pending_exception=0x0012fd87) Line 116 + 0x25 bytesC++
v8_mksnapshot.exe!v8::internal::Genesis::CompileScriptCached(v8::internal::Vectorchar
const name={...}, v8::internal::Handlev8::internal::String
source={...}, v8::internal::SourceCodeCache * cache=0x00513f10,
v8::Extension * extension=0x, bool use_runtime_context=true)
Line 884 + 0x19 bytes C++
v8_mksnapshot.exe!v8::internal::Genesis::CompileNative(v8::internal::Vectorchar
const name={...}, v8::internal::Handlev8::internal::String
source={...}) Line 836 + 0x44 bytesC++
v8_mksnapshot.exe!v8::internal::Genesis::InstallNatives() Line 1039
+ 0x2a bytesC++
v8_mksnapshot.exe!v8::internal::Genesis::Genesis(v8::internal::Handlev8::internal::Object
global_object={...}, v8::Handlev8::ObjectTemplate
global_template={...}, v8::ExtensionConfiguration *
extensions=0x0012fef8) Line 1464 + 0x7 bytes C++
v8_mksnapshot.exe!v8::internal::Bootstrapper::CreateEnvironment(v8::internal::Handlev8::internal::Object
global_object={...}, v8::Handlev8::ObjectTemplate
global_template={...}, v8::ExtensionConfiguration *
extensions=0x0012fef8) Line 352C++
v8_mksnapshot.exe!v8::Context::New(v8::ExtensionConfiguration *
extensions=0x0012fef8, v8::Handlev8::ObjectTemplate
global_template={...}, v8::Handlev8::Value global_object={...})
Line 2245 + 0x19 bytes C++
v8_mksnapshot.exe!main(int argc=2, char * * argv=0x00963c40) Line
165 + 0x29 bytesC++
v8_mksnapshot.exe!__tmainCRTStartup() Line 327 + 0x12 bytesC
kernel32.dll!7c816fd7()
[Frames below may be incorrect and/or missing, no symbols loaded for
kernel32.dll]
On Fri, Feb 20, 2009 at 11:54 AM, Eric Seidel esei...@chromium.org wrote:
I'm trying to build Chrome this morning and v8_mksnapshot.exe is crashing?
This is a clean build.
Thoughts?
-eric
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Re: staying on top of layout tests
Do we plan to live on the edge of the wave once we're entirely unforked, and never do merges again? - Pam On Fri, Feb 20, 2009 at 11:01 AM, Darin Fisher da...@chromium.org wrote: This sounds good to me as a temporary measure while we are still doing merges. We are supposed to be unforked by the end of the quarter, right? ;-) -Darin On Thu, Feb 19, 2009 at 2:49 PM, Ojan Vafai o...@chromium.org wrote: In the spirit of trying to fix all the layout tests that represent real regressions since our initial launch, I've just committed a changelist that defers the tests that are failing that are new to webkit since the revision of our launch or whose expectations changed upstream (the latter was only a couple tests, the former was almost 80 tests). If people think this is an awful idea, I can rollback. I don't think it makes sense to block releases to the stable channel on new tests that we've never passed. My biggest concern with each release is breaking sites that previously used to work in Chrome. New tests, for the most part, don't represent regressions like that. Does it make sense to make a policy of deferring new, failing tests from a webkit merge by default. The person doing the merge should put a good faith effort into getting it fixed, but it shouldn't block cutting a release. Eventually we'll get to a point where we only have deferred tests left and we can start tackling that long list of tests without having it hinder our ability to push releases to the stable channel. Ojan --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: staying on top of layout tests
Seems to me that the ideal situation down the road would be a buildbot that lives on tip of tree webkit.org, runs all the tests and every green build auto-updates the webkit revision we pull. Even in that case, we will have *at least* a couple build breakages a day from new tests that we don't pass. I'm OK with needing manual intervention to green the build and get the autoupdating working again (i.e. add the tests to the test lists) and we should work hard to make sure we fix the tests as soon as possible, but we still shouldn't block cutting a release on these tests. So, while unforking will make the burden of keeping up considerably less painful, we'll still need considerable effort devoted towards keeping the tests passing. Ojan On Fri, Feb 20, 2009 at 12:16 PM, Pam Greene p...@chromium.org wrote: Do we plan to live on the edge of the wave once we're entirely unforked, and never do merges again? - Pam On Fri, Feb 20, 2009 at 11:01 AM, Darin Fisher da...@chromium.org wrote: This sounds good to me as a temporary measure while we are still doing merges. We are supposed to be unforked by the end of the quarter, right? ;-) -Darin On Thu, Feb 19, 2009 at 2:49 PM, Ojan Vafai o...@chromium.org wrote: In the spirit of trying to fix all the layout tests that represent real regressions since our initial launch, I've just committed a changelist that defers the tests that are failing that are new to webkit since the revision of our launch or whose expectations changed upstream (the latter was only a couple tests, the former was almost 80 tests). If people think this is an awful idea, I can rollback. I don't think it makes sense to block releases to the stable channel on new tests that we've never passed. My biggest concern with each release is breaking sites that previously used to work in Chrome. New tests, for the most part, don't represent regressions like that. Does it make sense to make a policy of deferring new, failing tests from a webkit merge by default. The person doing the merge should put a good faith effort into getting it fixed, but it shouldn't block cutting a release. Eventually we'll get to a point where we only have deferred tests left and we can start tackling that long list of tests without having it hinder our ability to push releases to the stable channel. Ojan --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Fix inspector load. This method is called on InspectorController...
-chromium-reviews, +chromium-dev Not really sure. It seems to me that we need to send patches upstream to make InspectorController not depend directly on JSC. It doesn't seem like it should need to interact so directly with JSC. It's a non-trivial amount of work. Is there another way we could tackle this? Ojan On Fri, Feb 20, 2009 at 12:21 PM, dglaz...@chromium.org wrote: LGTM. BTW, what's our plan on getting this file unforked? :) http://codereview.chromium.org/27007 --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: staying on top of layout tests
Yes. We will have a stable API (a real WebKit layer) that lives in svn.webkit.org. That will enable us to point the chromium source at either a stable version of WebKit or the latest tip-of-tree WebKit. The set of developers who work on WebKit will live on tip-of-tree and ensure that it is maintained. The rest of the Chrome developers will be able to work free of the usual WebKit churn. When we identify a good WebKit, we can roll DEPS to make everyone use that version by default. In other words, we will be able to work with WebKit just as we do with V8 today. -Darin On Fri, Feb 20, 2009 at 12:16 PM, Pam Greene p...@chromium.org wrote: Do we plan to live on the edge of the wave once we're entirely unforked, and never do merges again? - Pam On Fri, Feb 20, 2009 at 11:01 AM, Darin Fisher da...@chromium.org wrote: This sounds good to me as a temporary measure while we are still doing merges. We are supposed to be unforked by the end of the quarter, right? ;-) -Darin On Thu, Feb 19, 2009 at 2:49 PM, Ojan Vafai o...@chromium.org wrote: In the spirit of trying to fix all the layout tests that represent real regressions since our initial launch, I've just committed a changelist that defers the tests that are failing that are new to webkit since the revision of our launch or whose expectations changed upstream (the latter was only a couple tests, the former was almost 80 tests). If people think this is an awful idea, I can rollback. I don't think it makes sense to block releases to the stable channel on new tests that we've never passed. My biggest concern with each release is breaking sites that previously used to work in Chrome. New tests, for the most part, don't represent regressions like that. Does it make sense to make a policy of deferring new, failing tests from a webkit merge by default. The person doing the merge should put a good faith effort into getting it fixed, but it shouldn't block cutting a release. Eventually we'll get to a point where we only have deferred tests left and we can start tackling that long list of tests without having it hinder our ability to push releases to the stable channel. Ojan --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: staying on top of layout tests
Realistically though, the point at which we have a stable api is at least another quarter out, right? So, there are two proposals on the table: 1. From now on, defer any non-security/crash tests we've never passed (i.e. new tests from webkit merges that fail) 2. Same as proposal 1, except we also add a NOTIMPLEMENTED option for the tests of features we haven't turned on yet. Preferences? I'm happy to make either one happen. Ojan On Fri, Feb 20, 2009 at 12:33 PM, Darin Fisher da...@chromium.org wrote: Yes. We will have a stable API (a real WebKit layer) that lives in svn.webkit.org. That will enable us to point the chromium source at either a stable version of WebKit or the latest tip-of-tree WebKit. The set of developers who work on WebKit will live on tip-of-tree and ensure that it is maintained. The rest of the Chrome developers will be able to work free of the usual WebKit churn. When we identify a good WebKit, we can roll DEPS to make everyone use that version by default. In other words, we will be able to work with WebKit just as we do with V8 today. -Darin On Fri, Feb 20, 2009 at 12:16 PM, Pam Greene p...@chromium.org wrote: Do we plan to live on the edge of the wave once we're entirely unforked, and never do merges again? - Pam On Fri, Feb 20, 2009 at 11:01 AM, Darin Fisher da...@chromium.orgwrote: This sounds good to me as a temporary measure while we are still doing merges. We are supposed to be unforked by the end of the quarter, right? ;-) -Darin On Thu, Feb 19, 2009 at 2:49 PM, Ojan Vafai o...@chromium.org wrote: In the spirit of trying to fix all the layout tests that represent real regressions since our initial launch, I've just committed a changelist that defers the tests that are failing that are new to webkit since the revision of our launch or whose expectations changed upstream (the latter was only a couple tests, the former was almost 80 tests). If people think this is an awful idea, I can rollback. I don't think it makes sense to block releases to the stable channel on new tests that we've never passed. My biggest concern with each release is breaking sites that previously used to work in Chrome. New tests, for the most part, don't represent regressions like that. Does it make sense to make a policy of deferring new, failing tests from a webkit merge by default. The person doing the merge should put a good faith effort into getting it fixed, but it shouldn't block cutting a release. Eventually we'll get to a point where we only have deferred tests left and we can start tackling that long list of tests without having it hinder our ability to push releases to the stable channel. Ojan --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: staying on top of layout tests
No, I'm working on it now. We need stable APIs ASAP so that we can do the stable and tip-of-tree separation before we have finished unforking. We should be able to have a stable third_party/WebKit and a close to tip-of-tree third_party/WebKit. That will help us do releases in the short term. -Darin On Fri, Feb 20, 2009 at 12:37 PM, Ojan Vafai o...@chromium.org wrote: Realistically though, the point at which we have a stable api is at least another quarter out, right? So, there are two proposals on the table: 1. From now on, defer any non-security/crash tests we've never passed (i.e. new tests from webkit merges that fail) 2. Same as proposal 1, except we also add a NOTIMPLEMENTED option for the tests of features we haven't turned on yet. Preferences? I'm happy to make either one happen. Ojan On Fri, Feb 20, 2009 at 12:33 PM, Darin Fisher da...@chromium.org wrote: Yes. We will have a stable API (a real WebKit layer) that lives in svn.webkit.org. That will enable us to point the chromium source at either a stable version of WebKit or the latest tip-of-tree WebKit. The set of developers who work on WebKit will live on tip-of-tree and ensure that it is maintained. The rest of the Chrome developers will be able to work free of the usual WebKit churn. When we identify a good WebKit, we can roll DEPS to make everyone use that version by default. In other words, we will be able to work with WebKit just as we do with V8 today. -Darin On Fri, Feb 20, 2009 at 12:16 PM, Pam Greene p...@chromium.org wrote: Do we plan to live on the edge of the wave once we're entirely unforked, and never do merges again? - Pam On Fri, Feb 20, 2009 at 11:01 AM, Darin Fisher da...@chromium.orgwrote: This sounds good to me as a temporary measure while we are still doing merges. We are supposed to be unforked by the end of the quarter, right? ;-) -Darin On Thu, Feb 19, 2009 at 2:49 PM, Ojan Vafai o...@chromium.org wrote: In the spirit of trying to fix all the layout tests that represent real regressions since our initial launch, I've just committed a changelist that defers the tests that are failing that are new to webkit since the revision of our launch or whose expectations changed upstream (the latter was only a couple tests, the former was almost 80 tests). If people think this is an awful idea, I can rollback. I don't think it makes sense to block releases to the stable channel on new tests that we've never passed. My biggest concern with each release is breaking sites that previously used to work in Chrome. New tests, for the most part, don't represent regressions like that. Does it make sense to make a policy of deferring new, failing tests from a webkit merge by default. The person doing the merge should put a good faith effort into getting it fixed, but it shouldn't block cutting a release. Eventually we'll get to a point where we only have deferred tests left and we can start tackling that long list of tests without having it hinder our ability to push releases to the stable channel. Ojan --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Fix inspector load. This method is called on InspectorController...
I actually didn't mean to start this conversation. Is there still time to run away and hide? :) On a (slightly) more serious note, I agree with your assessment and I thought at first that there was some work being done on that. :DG On Fri, Feb 20, 2009 at 12:25 PM, Ojan Vafai o...@chromium.org wrote: -chromium-reviews, +chromium-dev Not really sure. It seems to me that we need to send patches upstream to make InspectorController not depend directly on JSC. It doesn't seem like it should need to interact so directly with JSC. It's a non-trivial amount of work. Is there another way we could tackle this? Ojan On Fri, Feb 20, 2009 at 12:21 PM, dglaz...@chromium.org wrote: LGTM. BTW, what's our plan on getting this file unforked? :) http://codereview.chromium.org/27007 --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: VS solution takes forever to load
11k directories for me on that path. Awesome find. ProjectSection(WebsiteProperties) = preProject Can't we just delete this section? or would VS put it back? if so maybe we can put some nonsense there so VS does not re-create it. On Feb 19, 3:47 pm, Finnur Thorarinsson fin...@chromium.org wrote: Dang. Erik beat me to it. I just found another person stating the same fix. :) Instead, I'll point out that what Paul is seeing is not unusual, it takes up to 2 and a half minute on my machine to shut down Visual Studio completely and it appears to hang most of that time. I never shoot it down though. Same problem with starting up the Chrome solution. I've heard MS is making scalability issues a high priority in their next version of Visual Studio, though, so someday we'll hopefully have a fix for that problem. -F On Thu, Feb 19, 2009 at 15:37, Erik Kay erik...@chromium.org wrote: Wow. That's really cool. The slow solution load time has been really pissing me off for a while now. Emptying this directory fixed this problem completely for me. I recommend everyone do this. The wacky bit about that directory is that (for me at least) it's a bunch (31000+) of empty directories. Just opening the directory up to look at it took almost 10 minutes for me. Someone on the net said it took him two hours to delete the files. I recommend that you do it from the command-line. I did some searching using my favorite search engine and found the following tidbit: === http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?... Our problem is that developers are accumulating massive numbers of directories and files (24,000+ directories in one case) in the %userroot%\Local Settings\ApplicationData\Microsoft\WebSiteCache directory. Our solutions tend to have upward of 150-200 projects so this is a real problem. We are also seeing the following unnecessary lines (for windows apps!) in our .sln files that seem to be causing the issue: ProjectSection(WebsiteProperties) = preProject Debug.AspNetCompiler.Debug = True Release.AspNetCompiler.Debug = False EndProjectSection === Apparently, the unnecessary insertion of these lines is a known bug in VS2005 that's fixed in VS2008. Maybe the new solution/project generator will solve this for us by omitting these lines from the sln. Erik On Thu, Feb 19, 2009 at 2:41 PM, Eric Roman ero...@chromium.org wrote: So I recently had the problem where loading chrome.sln: takes about 10 minutes (in other words, absurdly long). It seems this time the the problem was VS trying to load many hundreds of hundreds of files from ~/Local Settings/Application Data/Microsoft/WebsiteCache/* Not sure why that happened, but deleting WebsiteCache did help dramatically. Since super slow load times is a regular problem for me, I am wandering what workarounds others have. One thing I find myself frequently doing is to delete the chrome.ncb and build output directories. This usually shaves off a couple minutes for me, and is marginally less disruptive to rebuild than be stuck waiting for the project to load. Thanks! --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
