We have previously been linking against V8 from VS2003 (only a few minor tweaks required) until recently. Now we're moving to VS2008, we've spotted an issue in V8, now exposed due to a change in default exception handling behaviour between the two compilers (async vs sync: http://msdn.microsoft.com/en-us/library/7f10tsf4.aspx)
If a limit is undefined, coming into StringSplit, then the max value of an unsigned int is set: 0xffffffff. This will subsequently travel through various internal calls, down to v8::Internal::FastD2I, which is commented with // The result is unspecified if x is infinite or NaN, or if the rounded // integer value is outside the range of type int. Now, we are able to call into v8 via COM, and this is where the issue was showing up: First-chance exception at 0x1c399f95 (v8_g.dll) in EXCEL.EXE: 0xC00002B5: Multiple floating point traps. First-chance exception at 0x1c202e97 (v8_g.dll) in EXCEL.EXE: 0xC0000005: Access violation reading location 0xfffffffd. Looks like v8 doesn't catch the hardware exception, but our COM proxy does (hardware exception is set there with _control87) and, due to the aforementioned changes in exception handling, the stack does not unwind properly, leaving us with a stale handle in the clear_list, and things spiral down from there, resulting in errors, badness, and much wailing & gnashing of teeth ;) The following one-line patch to src/string.js fixes the problem, by ensuring that the limit remains within _signed_ int boundaries: 583c583 < limit = (IS_UNDEFINED(limit)) ? 0xffffffff : TO_UINT32(limit); --- > limit = (IS_UNDEFINED(limit)) ? 0x0fffffff : TO_INT32(limit); With this in place, no more hardware floating point errors, and all is well. Regards, -Alex -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev
