I tried replying within the google group, but both times my message got
deleted - no idea why.   Anyhoo, trying via email...

No, nothing non-deterministic about this path specifically - the variable
gets set at the beginning and checked later during processing.  No
dependencies.

I'll try those options - thanks.  I was thinking a heap corruption issue,
too, especially since it's context specific.

On Tue, Apr 3, 2018 at 11:03 AM, Alon Zakai <alonza...@gmail.com> wrote:

> Is there anything nondeterministic here? The results on different OSes and
> browsers should be 100% identical except for things like random numbers,
> input events, etc. (unless you are seeing a browser bug).
>
> For debugging purposes you can build with -s DETERMINISTIC=1 which will
> force random numbers and timer events to be identical as well. Also worth
> building with ASSERTIONS and SAFE_HEAP, as an error like this might be a
> stack overflow or a heap corruption.
>
> On Tue, Apr 3, 2018 at 7:50 AM, Jeff Schindler <jas...@gmail.com> wrote:
>
>> We have some audio processing C code that we've brought to JS via
>> emscripten.  We're seeing odd behavior with the heap under certain
>> conditions.  We have a boolean value that we are setting, which is later
>> checked to determine the processing path.  In the right context, this
>> boolean, which resides in the HEAP32 array, somehow gets changed and
>> processing proceeds incorrectly.  We are seeing this within a certain
>> context only (so far) on Windows machines (tested in latest Chrome and
>> Firefox).  On Mac Chrome and Firefox, the HEAP32 check comes back as
>> expected.  What's really odd, and probably because of my naiveté on how
>> emscripten actually does its work, is that upon debugging on the Mac, I can
>> see that the first (and only the first) time the code checks the boolean,
>> it's looking at a different location than I would expect it to look (ie it
>> doesn't check the location that actually gets set when the boolean is
>> set).  On Windows, when it doesn't work, it always uses the expected
>> location and on that first check, it has the wrong value.  To further add
>> confusion, we have another JS client app where we're using the exact same
>> code and it works fine with it on the same Windows machine.  If anyone has
>> any insight at all, it'd be greatly appreciated!
>>
>> If it's useful, here are snippets of the relevant asm.js code:
>>
>> // set the boolean, where $0 is a passed parameter
>> $0 = $0 | 0;
>> var label = 0,
>> sp = 0;
>> sp = STACKTOP;
>> HEAP32[(169880) >> 2] = $0;
>>
>> // check the boolean, where $1 is a passed parameter
>> // the $6 var has the incorrect value on windows
>> // on the mac, $4 is 339904 on the first check, and then 169889 thereafter
>> // on windows, $4 is always 169889 when it fails
>> // note that on the mac, both heap locations have the correct value
>> $4 = ((($1)) + 24 | 0);
>> $5 = HEAP32[$4 >> 2] | 0;
>> $6 = ($5 | 0) != (0);
>> $7 = ($0 | 0) != (2);
>> $or$cond = $7 | $6;
>> if ($or$cond) {
>> return;
>> }
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "emscripten-discuss" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to emscripten-discuss+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to