My favorites | Sign in
Logo
v8
                
Details: Show all Hide all

Yesterday

  • 25 hours ago
    issue 561 (Compatibility patch for MSVC 2003) reported by andrey.semashev   -   Please, find the patch attached. The patch fixes the following problems: 1. Fixes compilation with MSVC 2003. Unlike the solution mentioned in the wiki, does not change the public interface of v8. The fix includes changing a few constructors and functuions with default argument values, adding some missing includes, fixing a for loop scope issue and removing dependency on CRT features that are not available in MSVC 2003. 2. Fixes issue 481. 3. Weakens dependency on RtlCaptureContext, which is only available since Windows XP. The function is also not available in Platform SDK shipped with MSVC 2003. If the function is not found in run time, the context is acquired from an artifical structured exception. The patch is against trunk, revision 3528.
    Please, find the patch attached. The patch fixes the following problems: 1. Fixes compilation with MSVC 2003. Unlike the solution mentioned in the wiki, does not change the public interface of v8. The fix includes changing a few constructors and functuions with default argument values, adding some missing includes, fixing a for loop scope issue and removing dependency on CRT features that are not available in MSVC 2003. 2. Fixes issue 481. 3. Weakens dependency on RtlCaptureContext, which is only available since Windows XP. The function is also not available in Platform SDK shipped with MSVC 2003. If the function is not found in run time, the context is acquired from an artifical structured exception. The patch is against trunk, revision 3528.
  • 26 hours ago
    issue 560 (v8::internal::Context::global_context ReadAV@NULL (94b1c4f5f...) changed by kasperl@chromium.org   -  
    Status: Duplicate
    Status: Duplicate
  • 26 hours ago
    issue 555 (Reliability crash in NewClosure code) commented on by kasperl@chromium.org   -   Issue 560 has been merged into this issue.
    Issue 560 has been merged into this issue.
  • 26 hours ago
    issue 560 (v8::internal::Context::global_context ReadAV@NULL (94b1c4f5f...) reported by skylined@chromium.org   -   While fuzzing HTTP in Chromium, I stumbled upon a "Attempt to read from NULL pointer (+0x13) in v8::internal::Context::global_context". I can't make heads or tails of it and I can't reproduce it either. Luckily, I was running Chromium in a debugger and my framework automatically extracted the attached information. I hope it helps you figure out what happened and fix the issue.
    While fuzzing HTTP in Chromium, I stumbled upon a "Attempt to read from NULL pointer (+0x13) in v8::internal::Context::global_context". I can't make heads or tails of it and I can't reproduce it either. Luckily, I was running Chromium in a debugger and my framework automatically extracted the attached information. I hope it helps you figure out what happened and fix the issue.
  • 35 hours ago
    issue 428 (Use of static variable builtin_passed_function should be rem...) changed by vita...@chromium.org   -  
    Status: Started
    Owner: vita...@chromium.org
    Status: Started
    Owner: vita...@chromium.org

Last 7 days

  • Dec 28, 2009
    r3528 (Faster handling of string indexing using [] with a SMI index...) committed by fschnei...@chromium.org   -   Faster handling of string indexing using [] with a SMI index. Instead of falling back to calling GetObjectProperty we call GetCharAt directly if the object is a string and the key in a SMI. Review URL: http://codereview.chromium.org/522015
    Faster handling of string indexing using [] with a SMI index. Instead of falling back to calling GetObjectProperty we call GetCharAt directly if the object is a string and the key in a SMI. Review URL: http://codereview.chromium.org/522015
  • Dec 28, 2009
    issue 559 (MacOSX 10.6.2 build r3521 in debug mode fail.) commented on by kasperl@chromium.org   -   Due to issues on certain Linux x64 machines, I had to rewrite the patch a bit. The new, revised code is live in the latest bleeding_edge and trunk versions (2.0.5.4).
    Due to issues on certain Linux x64 machines, I had to rewrite the patch a bit. The new, revised code is live in the latest bleeding_edge and trunk versions (2.0.5.4).
  • Dec 28, 2009
    r3527 (Tagging version 2.0.5.4) committed by kasperl@chromium.org   -   Tagging version 2.0.5.4
    Tagging version 2.0.5.4
  • Dec 28, 2009
    r3526 (Merge r3525 to trunk. Review URL: http://codereview.chromium...) committed by kasperl@chromium.org   -   Merge r3525 to trunk. Review URL: http://codereview.chromium.org/519008
    Merge r3525 to trunk. Review URL: http://codereview.chromium.org/519008
  • Dec 28, 2009
    r3525 (Second attempt at fixing issue 559. Review URL: http://coder...) committed by kasperl@chromium.org   -   Second attempt at fixing issue 559 . Review URL: http://codereview.chromium.org/519007
    Second attempt at fixing issue 559 . Review URL: http://codereview.chromium.org/519007
  • Dec 28, 2009
    issue 460 (Support ES5 Object.create) changed by kasperl@chromium.org   -   Assigning to Erik Corry who has been working on implementing Object.create; see r3438.
    Status: Assigned
    Owner: erik.corry
    Assigning to Erik Corry who has been working on implementing Object.create; see r3438.
    Status: Assigned
    Owner: erik.corry
  • Dec 28, 2009
    r3524 (Tagging version 2.0.5.3) committed by kasperl@chromium.org   -   Tagging version 2.0.5.3
    Tagging version 2.0.5.3
  • Dec 28, 2009
    issue 559 (MacOSX 10.6.2 build r3521 in debug mode fail.) Status changed by kasperl@chromium.org   -   Merged to trunk in r3523 (V8 version 2.0.5.3).
    Status: Fixed
    Merged to trunk in r3523 (V8 version 2.0.5.3).
    Status: Fixed
  • Dec 28, 2009
    r3523 (Merge r3522 to trunk. Review URL: http://codereview.chromium...) committed by kasperl@chromium.org   -   Merge r3522 to trunk. Review URL: http://codereview.chromium.org/518018
    Merge r3522 to trunk. Review URL: http://codereview.chromium.org/518018
  • Dec 28, 2009
    issue 559 (MacOSX 10.6.2 build r3521 in debug mode fail.) changed by kasperl@chromium.org   -   Thanks a lot for the patch. I've landed a slightly simplified version of it (without the static_cast) in r3522 on bleeding_edge. I'll go ahead and merge it to trunk right away.
    Status: Assigned
    Owner: kasp...@chromium.org
    Thanks a lot for the patch. I've landed a slightly simplified version of it (without the static_cast) in r3522 on bleeding_edge. I'll go ahead and merge it to trunk right away.
    Status: Assigned
    Owner: kasp...@chromium.org
  • Dec 28, 2009
    r3522 (Land http://codereview.chromium.org/509029 (slightly simplif...) committed by kasperl@chromium.org   -   Land http://codereview.chromium.org/509029 (slightly simplified).
    Land http://codereview.chromium.org/509029 (slightly simplified).
  • Dec 27, 2009
    issue 559 (MacOSX 10.6.2 build r3521 in debug mode fail.) commented on by lycboy   -   The patch works fine:-) Thank you coldredlemur~ Someone please help me close this bug, thanks.
    The patch works fine:-) Thank you coldredlemur~ Someone please help me close this bug, thanks.
  • Dec 27, 2009
    issue 413 (GCC 4.4 fails to compile current version, over strict aliasi...) commented on by itoshkov   -   Same stuff as in comment 11, except I'm on a 32 bit karmik. It seems that the problem is, that '-fno-strict-aliasing' is set only for GCC_DTOA_EXTRA_FLAGS. I added it to GCC_EXTRA_FLAGS as well and it worked. I'm attaching a small patch, that does that.
    Same stuff as in comment 11, except I'm on a 32 bit karmik. It seems that the problem is, that '-fno-strict-aliasing' is set only for GCC_DTOA_EXTRA_FLAGS. I added it to GCC_EXTRA_FLAGS as well and it worked. I'm attaching a small patch, that does that.
  • Dec 26, 2009
    issue 559 (MacOSX 10.6.2 build r3521 in debug mode fail.) commented on by coldredlemur   -   see http://codereview.chromium.org/509029
  • Dec 26, 2009
    issue 559 (MacOSX 10.6.2 build r3521 in debug mode fail.) reported by lycboy   -   Build in release mode is OK, but debug mode failed. ------ OS: MacOSX 10.6.2 v8 revision: r3521 g++ version: i686-apple-darwin10-g++-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5646) (dot 1) ------ Build command: scons mode=debug arch=x64 library=shared snapshot=on visibility=default ------ Error messages: src/x64/fast-codegen-x64.cc: In member function 'void v8::internal::FastCodeGenerator::StoreToFrameField(int, v8::internal::Register)': src/x64/fast-codegen-x64.cc:1681: error: call of overloaded 'CheckEqualsHelper(const char [28], int, const char [68], long int, const char [36], intptr_t)' is ambiguous src/checks.h:75: note: candidates are: void CheckEqualsHelper(const char*, int, const char*, int, const char*, int) src/checks.h:89: note: void CheckEqualsHelper(const char*, int, const char*, int64_t, const char*, int64_t) src/checks.h:187: note: void CheckEqualsHelper(const char*, int, const char*, double, const char*, double) scons: *** [obj/debug/x64/fast-codegen-x64.os] Error 1
    Build in release mode is OK, but debug mode failed. ------ OS: MacOSX 10.6.2 v8 revision: r3521 g++ version: i686-apple-darwin10-g++-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5646) (dot 1) ------ Build command: scons mode=debug arch=x64 library=shared snapshot=on visibility=default ------ Error messages: src/x64/fast-codegen-x64.cc: In member function 'void v8::internal::FastCodeGenerator::StoreToFrameField(int, v8::internal::Register)': src/x64/fast-codegen-x64.cc:1681: error: call of overloaded 'CheckEqualsHelper(const char [28], int, const char [68], long int, const char [36], intptr_t)' is ambiguous src/checks.h:75: note: candidates are: void CheckEqualsHelper(const char*, int, const char*, int, const char*, int) src/checks.h:89: note: void CheckEqualsHelper(const char*, int, const char*, int64_t, const char*, int64_t) src/checks.h:187: note: void CheckEqualsHelper(const char*, int, const char*, double, const char*, double) scons: *** [obj/debug/x64/fast-codegen-x64.os] Error 1

Last 30 days

  • Dec 23, 2009
    issue 558 (Math.random yields <= 30 bits) reported by r...@google.com   -   Calling Math.random() * 4294967296 (= 2^32) always yields a number divisible by 4, indicating that there are really only 30 bits in the mantissa of Math.random() that are ever non-zero. It would be nice to have at least 32 bits worth of randomness so that generation of random 32-bit integers would require only a single call to Math.random(). This issue was identified by a GWT user at the URL below. While we can work around this issue in GWT if need be, it would be nice to have an improved source of randomness in Chrome/V8. A simple histgram check in Chrome, Safari, and Firefox indicates that the 4 LSBs of (Math.random() * 4294967296) are pretty evenly distributed in Safari and Firefox, but only take on the values 0, 4, 8, and 12 in Chrome. I'm running Chrome 4.0.249.30 on Mac OS X 10.5.8. GWT issue: http://code.google.com/p/google-web-toolkit/issues/detail?id=4372
    Calling Math.random() * 4294967296 (= 2^32) always yields a number divisible by 4, indicating that there are really only 30 bits in the mantissa of Math.random() that are ever non-zero. It would be nice to have at least 32 bits worth of randomness so that generation of random 32-bit integers would require only a single call to Math.random(). This issue was identified by a GWT user at the URL below. While we can work around this issue in GWT if need be, it would be nice to have an improved source of randomness in Chrome/V8. A simple histgram check in Chrome, Safari, and Firefox indicates that the 4 LSBs of (Math.random() * 4294967296) are pretty evenly distributed in Safari and Firefox, but only take on the values 0, 4, 8, and 12 in Chrome. I'm running Chrome 4.0.249.30 on Mac OS X 10.5.8. GWT issue: http://code.google.com/p/google-web-toolkit/issues/detail?id=4372
  • Dec 23, 2009
    issue 363 (ASSERT(catcher.HasCaught()); in v8::internal::Execution::Try...) Status changed by skylined@chromium.org   -   Verified with Chromium 4.0.278.0 (Developer Build 35139, WebKit 532.8, V8 2.0.5.2) This triggers a debugger breakpoint in `anonymous namespace'::OnNoMemory, which is what you would expect when you're consuming massive amounts of memory.
    Status: Fixed
    Verified with Chromium 4.0.278.0 (Developer Build 35139, WebKit 532.8, V8 2.0.5.2) This triggers a debugger breakpoint in `anonymous namespace'::OnNoMemory, which is what you would expect when you're consuming massive amounts of memory.
    Status: Fixed
  • Dec 23, 2009
    issue 362 (Nested brackets OOM crash in regular expression) Status changed by skylined@chromium.org   -   Still repros with Chromium 4.0.278.0 (Developer Build 35139, WebKit 532.8, V8 2.0.5.2) http://skypher.com/SkyLined/Repro/Opera/Opera%209.60%20SE-Recursion%232515c755/repro.html Is Chrome 4 using an old version of V8?
    Status: Assigned
    Still repros with Chromium 4.0.278.0 (Developer Build 35139, WebKit 532.8, V8 2.0.5.2) http://skypher.com/SkyLined/Repro/Opera/Opera%209.60%20SE-Recursion%232515c755/repro.html Is Chrome 4 using an old version of V8?
    Status: Assigned
  • Dec 23, 2009
    r3521 (Use a loop in generated code to allocate stack slots for fun...) committed by fschnei...@chromium.org   -   Use a loop in generated code to allocate stack slots for function with many local variables. If a function contains more than a certain number of locals (IA32: 9, X64: 6, ARM: 4) a loop for initializing the locals with 'undefined' is more compact. For less locals we unroll that loop by emitting a sequence of push instructions. Review URL: http://codereview.chromium.org/515012
    Use a loop in generated code to allocate stack slots for function with many local variables. If a function contains more than a certain number of locals (IA32: 9, X64: 6, ARM: 4) a loop for initializing the locals with 'undefined' is more compact. For less locals we unroll that loop by emitting a sequence of push instructions. Review URL: http://codereview.chromium.org/515012
  • Dec 23, 2009
    r3520 (- Reordered the instructions in the inlined allocation code ...) committed by bak@chromium.org   -   - Reordered the instructions in the inlined allocation code to space dependent instructions. - Replaced the or instruction with lea. Review URL: http://codereview.chromium.org/521003
    - Reordered the instructions in the inlined allocation code to space dependent instructions. - Replaced the or instruction with lea. Review URL: http://codereview.chromium.org/521003
  • Dec 23, 2009
    issue 555 (Reliability crash in NewClosure code) commented on by kasperl@chromium.org   -   Still happens from time to time even with the "fix" in version 2.0.5.2 (which went live in Chromium at revision 34088). The latest crash happened with Chromium revision 35202.
    Still happens from time to time even with the "fix" in version 2.0.5.2 (which went live in Chromium at revision 34088). The latest crash happened with Chromium revision 35202.
  • Dec 22, 2009
    issue 436 (Numeric results are wrong on some systems due to x87 extende...) commented on by erig...@google.com   -   Related to http://code.google.com/p/google-caja/issues/detail?id=1175
  • Dec 22, 2009
    issue 436 (Numeric results are wrong on some systems due to x87 extende...) commented on by erig...@google.com   -   > The impact of extended-precision results [...] seems to be minimal, > and any intrusive changes to solve this problem would cause > performance hits. Should this be marked as "will not fix", or "fixed"? The Caja group is designing an enforced-deterministic subset of Cajita, for use for replicated computations -- both for high availability under partition as well as low latency query operations (as would benefit the planned Caja embeddings in Wave). Such deterministic replayability also benefits security <http://www.eecs.berkeley.edu/~finifter/pure-ccs08.pdf> and recreation (imagine <http://fantasticcontraption.net/> in Cajita). With the exception of this floating point issue, we believe that an enhanced Cajita rewriting strategy can enforce all the remaining determinism issues at reasonable cost. However, if the basic floating point operations are not of a deterministic precision, we have been unable to invent any other means of recovering affordable determinism by rewriting.
    > The impact of extended-precision results [...] seems to be minimal, > and any intrusive changes to solve this problem would cause > performance hits. Should this be marked as "will not fix", or "fixed"? The Caja group is designing an enforced-deterministic subset of Cajita, for use for replicated computations -- both for high availability under partition as well as low latency query operations (as would benefit the planned Caja embeddings in Wave). Such deterministic replayability also benefits security <http://www.eecs.berkeley.edu/~finifter/pure-ccs08.pdf> and recreation (imagine <http://fantasticcontraption.net/> in Cajita). With the exception of this floating point issue, we believe that an enhanced Cajita rewriting strategy can enforce all the remaining determinism issues at reasonable cost. However, if the basic floating point operations are not of a deterministic precision, we have been unable to invent any other means of recovering affordable determinism by rewriting.
  • Dec 22, 2009
    r3519 (When promoting objects during a copying collection, promote ...) committed by kmilli...@chromium.org   -   When promoting objects during a copying collection, promote all non-large objects that cannot contain non-map-word pointers to other heap objects into the old data space. Review URL: http://codereview.chromium.org/502100
    When promoting objects during a copying collection, promote all non-large objects that cannot contain non-map-word pointers to other heap objects into the old data space. Review URL: http://codereview.chromium.org/502100
  • Dec 22, 2009
    r3518 (Make the FastCloneShallowArrayStub a bit prettier. TBR=fsch...) committed by kasperl@chromium.org   -   Make the FastCloneShallowArrayStub a bit prettier. TBR=fschneider@chromium.org Review URL: http://codereview.chromium.org/507069
    Make the FastCloneShallowArrayStub a bit prettier. TBR=fschneider@chromium.org Review URL: http://codereview.chromium.org/507069
  • Dec 22, 2009
    r3517 (Revert r3514 and r3515. The new cache is too large for some...) committed by ager@chromium.org   -   Revert r3514 and r3515. The new cache is too large for some tests that attempt to run with a small heap. Additionally, it can potentially keep a lot of string data alive and it is never flushed. Can we make it grow dynamically if used so that we can still start the VM with a small heap size? Review URL: http://codereview.chromium.org/503081
    Revert r3514 and r3515. The new cache is too large for some tests that attempt to run with a small heap. Additionally, it can potentially keep a lot of string data alive and it is never flushed. Can we make it grow dynamically if used so that we can still start the VM with a small heap size? Review URL: http://codereview.chromium.org/503081
  • Dec 22, 2009
    r3516 (Use one runtime call for creating object/array literals in t...) committed by fschnei...@chromium.org   -   Use one runtime call for creating object/array literals in the code generator. The runtime function checks if it needs to create a boilerplate object or if it can clone from an existing boilerplate. This is already done in the top-level compiler. Review URL: http://codereview.chromium.org/507036
    Use one runtime call for creating object/array literals in the code generator. The runtime function checks if it needs to create a boilerplate object or if it can clone from an existing boilerplate. This is already done in the top-level compiler. Review URL: http://codereview.chromium.org/507036
  • Dec 22, 2009
    r3515 (Fix linto.) committed by kasperl@chromium.org   -   Fix linto.
    Fix linto.
  • Dec 22, 2009
    r3514 (- Increased size of number string cache. - Change the instru...) committed by bak@chromium.org   -   - Increased size of number string cache. - Change the instruction order for inlined allocation. Review URL: http://codereview.chromium.org/501170
    - Increased size of number string cache. - Change the instruction order for inlined allocation. Review URL: http://codereview.chromium.org/501170
  • Dec 22, 2009
    issue 557 (Implement and use GenericUnaryOpStub on 64 bit and ARM) reported by erik.corry   -   As in http://codereview.chromium.org/503079
  • Dec 22, 2009
    r3513 (Add fast case stub for BIT_NOT. Review URL: http://coderevie...) committed by kasperl@chromium.org   -   Add fast case stub for BIT_NOT. Review URL: http://codereview.chromium.org/503079
    Add fast case stub for BIT_NOT. Review URL: http://codereview.chromium.org/503079
  • Dec 22, 2009
    r3512 (Check for undefined in the binary operation stub when conver...) committed by ager@chromium.org   -   Check for undefined in the binary operation stub when convertion to int32 for bitops. undefined converts to zero in ToInt32 conversions. Review URL: http://codereview.chromium.org/508020
    Check for undefined in the binary operation stub when convertion to int32 for bitops. undefined converts to zero in ToInt32 conversions. Review URL: http://codereview.chromium.org/508020
  • Dec 21, 2009
    r3511 (Tagging version 2.0.5.2) committed by kasperl@chromium.org   -   Tagging version 2.0.5.2
    Tagging version 2.0.5.2
  • Dec 21, 2009
    issue 555 (Reliability crash in NewClosure code) commented on by kasperl@chromium.org   -   The issue is that we somehow get an illegal context that has a NULL closure reference (and probably a messed up map too) into the runtime system in the Runtime_NewClosure function. Experimental fix submitted in r3509 / pushed to trunk in r3510 (V8 version 2.0.5.2).
    The issue is that we somehow get an illegal context that has a NULL closure reference (and probably a messed up map too) into the runtime system in the Runtime_NewClosure function. Experimental fix submitted in r3509 / pushed to trunk in r3510 (V8 version 2.0.5.2).
  • Dec 21, 2009
    r3510 (Merge r3505 and r3509 to trunk. Review URL: http://coderevie...) committed by kasperl@chromium.org   -   Merge r3505 and r3509 to trunk. Review URL: http://codereview.chromium.org/505062
    Merge r3505 and r3509 to trunk. Review URL: http://codereview.chromium.org/505062
  • Dec 21, 2009
    r3509 (Very experimental fix for issue 555. Review URL: http://code...) committed by kasperl@chromium.org   -   Very experimental fix for issue 555. Review URL: http://codereview.chromium.org/508006
    Very experimental fix for issue 555. Review URL: http://codereview.chromium.org/508006
  • Dec 21, 2009
    r3508 (Optimize implementation of Math.floor a little by special ca...) committed by erik.corry   -   Optimize implementation of Math.floor a little by special casing the comparison it uses in the code generator. Use Math.floor for date operations. Review URL: http://codereview.chromium.org/509007
    Optimize implementation of Math.floor a little by special casing the comparison it uses in the code generator. Use Math.floor for date operations. Review URL: http://codereview.chromium.org/509007
  • Dec 21, 2009
    issue 464 (x64 crash on smi conversion) commented on by phajdan...@chromium.org   -   Issue chromium:24556 has been merged into this issue.
    Issue chromium:24556 has been merged into this issue.
  • Dec 21, 2009
    r3507 (Remove complicated Math.sin and Math.cos optimizations that ...) committed by ager@chromium.org   -   Remove complicated Math.sin and Math.cos optimizations that do not buy us much. Review URL: http://codereview.chromium.org/509006
    Remove complicated Math.sin and Math.cos optimizations that do not buy us much. Review URL: http://codereview.chromium.org/509006
  • Dec 21, 2009
    r3506 (Optimize sine and cosine by checking up front if the fsin or...) committed by ager@chromium.org   -   Optimize sine and cosine by checking up front if the fsin or fcos operation can throw an exception. Review URL: http://codereview.chromium.org/504073
    Optimize sine and cosine by checking up front if the fsin or fcos operation can throw an exception. Review URL: http://codereview.chromium.org/504073
  • Dec 21, 2009
    issue 270 (Add Blob type to api for holding binary data) commented on by christian.plesner.hansen   -   There is an open changelist for this (http://codereview.chromium.org/391068/show) but it may end up not being landed. The consensus seems to be that Object::SetIndexedPropertiesToExternalArrayData is actually better suited for most of the use cases for a Blob data type.
    There is an open changelist for this (http://codereview.chromium.org/391068/show) but it may end up not being landed. The consensus seems to be that Object::SetIndexedPropertiesToExternalArrayData is actually better suited for most of the use cases for a Blob data type.
  • Dec 21, 2009
    r3505 (The number of heap slots stored in a scope includes the fixe...) committed by kasperl@chromium.org   -   The number of heap slots stored in a scope includes the fixed contexts slots. Take this into account when using the new, fast context creation path to avoid allocating too many slots (wasteful). Review URL: http://codereview.chromium.org/501148
    The number of heap slots stored in a scope includes the fixed contexts slots. Take this into account when using the new, fast context creation path to avoid allocating too many slots (wasteful). Review URL: http://codereview.chromium.org/501148
  • Dec 21, 2009
    issue 556 (Avoid checking flags after fisttp on 64 bit) reported by erik.corry   -   Implement something like http://codereview.chromium.org/509001
    Implement something like http://codereview.chromium.org/509001
  • Dec 21, 2009
    r3504 (Bring back the fisttp instruction on machines with SSE3, but...) committed by erik.corry   -   Bring back the fisttp instruction on machines with SSE3, but check the input so we don't have to check the exception flags afterwards. Review URL: http://codereview.chromium.org/509001
    Bring back the fisttp instruction on machines with SSE3, but check the input so we don't have to check the exception flags afterwards. Review URL: http://codereview.chromium.org/509001
  • Dec 20, 2009
    issue 555 (Reliability crash in NewClosure code) reported by kasperl@chromium.org   -   Stack trace: chrome_23a0000!v8::internal::Context::global_context+0x42 [c:\b\slave\chromium-rel-xp\build\src\v8\src\contexts.cc @ 59] chrome_23a0000!v8::internal::Top::ComputeLocation+0x12 [c:\b\slave\chromium-rel-xp\build\src\v8\src\top.cc @ 671] chrome_23a0000!v8::internal::Top::DoThrow+0xe4 [c:\b\slave\chromium-rel- xp\build\src\v8\src\top.cc @ 770] chrome_23a0000!v8::internal::Top::ThrowIllegalOperation+0xf [c:\b\slave\chromium-rel-xp\build\src\v8\src\top.cc @ 620] chrome_23a0000!v8::internal::Runtime_NewClosure+0x5b [c:\b\slave\chromium- rel-xp\build\src\v8\src\runtime.cc @ 4502] chrome_23a0000!v8::internal::Invoke+0xc2 [c:\b\slave\chromium-rel- xp\build\src\v8\src\execution.cc @ 95] chrome_23a0000!v8::internal::Execution::Call+0x26 [c:\b\slave\chromium-rel- xp\build\src\v8\src\execution.cc @ 120] See: http://crash-staging/reportdetail?reportid=ffa9e713c84510a0 http://crash-staging/reportdetail?reportid=d44ce2f6c909568f
    Stack trace: chrome_23a0000!v8::internal::Context::global_context+0x42 [c:\b\slave\chromium-rel-xp\build\src\v8\src\contexts.cc @ 59] chrome_23a0000!v8::internal::Top::ComputeLocation+0x12 [c:\b\slave\chromium-rel-xp\build\src\v8\src\top.cc @ 671] chrome_23a0000!v8::internal::Top::DoThrow+0xe4 [c:\b\slave\chromium-rel- xp\build\src\v8\src\top.cc @ 770] chrome_23a0000!v8::internal::Top::ThrowIllegalOperation+0xf [c:\b\slave\chromium-rel-xp\build\src\v8\src\top.cc @ 620] chrome_23a0000!v8::internal::Runtime_NewClosure+0x5b [c:\b\slave\chromium- rel-xp\build\src\v8\src\runtime.cc @ 4502] chrome_23a0000!v8::internal::Invoke+0xc2 [c:\b\slave\chromium-rel- xp\build\src\v8\src\execution.cc @ 95] chrome_23a0000!v8::internal::Execution::Call+0x26 [c:\b\slave\chromium-rel- xp\build\src\v8\src\execution.cc @ 120] See: http://crash-staging/reportdetail?reportid=ffa9e713c84510a0 http://crash-staging/reportdetail?reportid=d44ce2f6c909568f