This is a problem with imports into WASM.

Looks like we need to handle this case in WASM instantiation.

# This one is the other way around:
function __f_7(v, rand) {
  var __v_10 = Object.getOwnPropertyNames(v);
  return __v_10[rand % __v_10.length];
}
function __f_6(stdlib, foreign, buffer) {
  "use asm";
  var __v_9 = new stdlib.Float64Array(buffer);
  function __f_5() {
  }
  return {__f_5: __f_5};
}
Array.prototype.__proto__ = {3: ""};
Array.prototype.__proto__.__proto__ = {7: 6};
__v_9 = [0, 1, , , 4, 5, , , , 9]
__v_9.splice(4, 1)
__v_9.__defineGetter__(__f_7(__v_9, 1689439720), function() {; return __f_6(); });
 __v_9[8]


# Compared default with validate_asm

# Flags of default:
--abort_on_stack_overflow --expose-gc --allow-natives-syntax --invoke-weak-callbacks --omit-quit  --random-seed 2098614004
# Flags of validate_asm:
--abort_on_stack_overflow --expose-gc --allow-natives-syntax --invoke-weak-callbacks --omit-quit  --random-seed 2098614004 --validate-asm

Difference:
- output13_noturbo_opt/fuzz-02336.js.minimized:7: TypeError: Cannot read property 'Float64Array' of undefined

### Start of configuration default:
output13_noturbo_opt/fuzz-02336.js.minimized:7: TypeError: Cannot read property 'Float64Array' of undefined
  var __v_9 = new stdlib.Float64Array(buffer);
                        ^
TypeError: Cannot read property 'Float64Array' of undefined
    at __f_6 (output13_noturbo_opt/fuzz-02336.js.minimized:7:25)
    at Array.<anonymous> (output13_noturbo_opt/fuzz-02336.js.minimized:16:71)
    at output13_noturbo_opt/fuzz-02336.js.minimized:17:7


### End of configuration default

### Start of configuration validate_asm:

### End of configuration validate_asm

As mentioned by Ben, it's a WASM problem.

Smaller repro. This case is spamming the correctness fuzzing workbench and blocks doing more fuzzing on validate_asm:

(function(a, b, c) {
  "use asm";
  var r = new a.Int8Array(c);
  return {};
})();

# Compared fullcode with validate_asm

# Flags of fullcode:
--abort_on_stack_overflow --expose-gc --allow-natives-syntax --invoke-weak-callbacks --omit-quit --es-staging  --random-seed -269105172 --nocrankshaft --turbo-filter=~
# Flags of validate_asm:
--abort_on_stack_overflow --expose-gc --allow-natives-syntax --invoke-weak-callbacks --omit-quit --es-staging  --random-seed -269105172 --validate-asm

Difference:
- /usr/local/google/home/machenbach/v8/clusterfuzz-data/fuzzers/workdir/output32_validate_asm/fuzz-00112.js.minimized:3: TypeError: Cannot read property 'Int8Array' of undefined

### Start of configuration fullcode:
/usr/local/google/home/machenbach/v8/clusterfuzz-data/fuzzers/workdir/output32_validate_asm/fuzz-00112.js.minimized:3: TypeError: Cannot read property 'Int8Array' of undefined
  var r = new a.Int8Array(c);
               ^
TypeError: Cannot read property 'Int8Array' of undefined
    at /usr/local/google/home/machenbach/v8/clusterfuzz-data/fuzzers/workdir/output32_validate_asm/fuzz-00112.js.minimized:3:16
    at /usr/local/google/home/machenbach/v8/clusterfuzz-data/fuzzers/workdir/output32_validate_asm/fuzz-00112.js.minimized:5:3


### End of configuration fullcode

### Start of configuration validate_asm:

### End of configuration validate_asm

Another strange case. The print causes an exception to be printed, though it doesn't take a parameter. If I pass e it prints two exceptions. But only one in fullcode.


try {
function foo(stdlib, foreign) {
  'use asm';
  var r = foreign.throwFunc;
  function bar() {
    r();
  }
  return bar;
}
  var __v_4 = foo();
} catch(e) { print(); }


# Compared fullcode with validate_asm

# Flags of fullcode:
--abort_on_stack_overflow --expose-gc --allow-natives-syntax --invoke-weak-callbacks --omit-quit --es-staging  --random-seed -396081663 --nocrankshaft --turbo-filter=~
# Flags of validate_asm:
--abort_on_stack_overflow --expose-gc --allow-natives-syntax --invoke-weak-callbacks --omit-quit --es-staging  --random-seed -396081663 --validate-asm

Difference:
+ TypeError: Asm.js -> WebAssembly instantiation: Import #0 module="throwFunc" error: FFI is not an object

### Start of configuration fullcode:


### End of configuration fullcode

### Start of configuration validate_asm:

TypeError: Asm.js -> WebAssembly instantiation: Import #0 module="throwFunc" error: FFI is not an object


### End of configuration validate_asm

Here a type conversion doesn't work:
function __f_2() {
  "use asm";
  function __f_3(a) {
    a = a | 0;
  }
  return {};
}
print(__f_2());

# Compared fullcode with validate_asm

# Flags of fullcode:
--abort_on_stack_overflow --expose-gc --allow-natives-syntax --invoke-weak-callbacks --omit-quit --es-staging --gc-interval=34 --inline-accessors --random-seed -1244519159 --nocrankshaft --turbo-filter=~
# Flags of validate_asm:
--abort_on_stack_overflow --expose-gc --allow-natives-syntax --invoke-weak-callbacks --omit-quit --es-staging --gc-interval=34 --inline-accessors --random-seed -1244519159 --validate-asm

Difference:
- [object Object]
+ 

### Start of configuration fullcode:
[object Object]

### End of configuration fullcode

### Start of configuration validate_asm:

/usr/local/google/home/machenbach/v8/clusterfuzz-data/fuzzers/workdir/output32_validate_asm/fuzz-00857.js.minimized:8: TypeError: Cannot convert object to primitive value
print(__f_2());
^
TypeError: Cannot convert object to primitive value
    at /usr/local/google/home/machenbach/v8/clusterfuzz-data/fuzzers/workdir/output32_validate_asm/fuzz-00857.js.minimized:8:1


### End of configuration validate_asm

Ben and I investigated further, and here is what we found:
(we used the code example on the very first comment)

First observation: It's really the gc() call which throws the exception, not bar({}, {}).

Our Theory is:
The AsmJs::IsStdlibValid check passes, as the error is in FFI, not stdlib. Hence, InstantiateAsmWasm is called, which detects the error, sets a pending exception, and returns nothing. Because nothing is returned, default code is being generated and executed, everything looks fine, until you call into the runtime the next time (on gc()). On that point, the pending exception is being thrown.

What we probably have to do is to check the imports before trying to instantiate wasm for the AsmJs module. Or, alternatively, don't set the exception, or clear it later (in Runtime_InstantiateAsmJs?).

The issue from comment 2 is now encountered separately as  issue 680110 . Will track and possibly suppress it there.

Is this wontix by now? Doesn't repro with current comparison.

I went through all the individual snippets above, all of them have been addressed with the new asm.js validator by now. Nothing left to be done here.