It happens with the Current Version IE on the Windows 8 machine (IE 11, Version 11.0.9600.17631)
On Friday, February 20, 2015 at 2:28:33 PM UTC-7, Alon Zakai wrote: > > "This' is not a function object" looks like a weird bug in IE9. Does it > happen in current versions of IE? > > - Alon > > > On Wed, Feb 18, 2015 at 2:04 PM, Ishaan Venkatesan <[email protected] > <javascript:>> wrote: > >> The screenshot of the error is attached for your reference. It shows that >> with "-s ALLOW_MEMORY_GROWTH=1", IE would fail when allocating 14MB of >> memory indicating "enlargeMemory" errors. Same error would happen with >> Chrome when allocating much bigger memories. >> >> On Tuesday, February 17, 2015 at 10:19:33 PM UTC-7, Alon Zakai wrote: >>> >>> What do you mean by fail? What specific error do you see in the console? >>> Is it the same across all of these? I would expect to see different ones, >>> as if memory growth is on, the only possible failure should be that the >>> browser runs out of memory, and that error message does not look like >>> emscripten's "cannot enlarge memory arrays" notification. >>> >>> - Alon >>> >>> >>> On Tue, Feb 17, 2015 at 8:03 PM, Ishaan Venkatesan < >>> [email protected]> wrote: >>> >>>> Hi Alon, >>>> >>>> I removed Windows-related code and attached the web application that >>>> should run on Linux & Mac. >>>> >>>> As to Firefox: >>>> 1 Without "-s ALLOW_MEMORY_GROWTH=1", memory allocation of 11,000,000 >>>> bytes would succeed (better than Chrome), but 12,000,000 bytes would fail >>>> 2. With "-s ALLOW_MEMORY_GROWTH=1", we could allocate 1G of memory >>>> without any problem (much better than Chrome). >>>> >>>> Thus the surprising result is really IE as you've pointed out. This is >>>> a big concern though, as my application would often allocate 100-200 M of >>>> memories, and cross-platform support is important. >>>> >>>> Do you happen to know any work around? I noticed that when the >>>> Javascript sends a large file to the C++ side by calling FS.writeFile(), >>>> the code would not crash on all browsers even when we are not setting "-s >>>> ALLOW_MEMORY_GROWTH=1".In the document here >>>> <http://kripken.github.io/emscripten-site/docs/api_reference/Filesystem-API.html>, >>>> >>>> it said that the default file system with Emscripten is actually >>>> implemented through memory (i.e. MEMFS). In other words, IE is able to >>>> handle large in-memory data (>500 M in my test) when the data is accessed >>>> through the file system API. I am wondering if it possible to allocate >>>> large blocks of memory in Emscripten by using MEMFS as the back-end? (not >>>> sure how) >>>> >>>> Thanks! >>>> >>>> On Tuesday, February 17, 2015 at 7:00:04 PM UTC-7, Alon Zakai wrote: >>>>> >>>>> I'm not on Windows so I can't build these. >>>>> >>>>> About 200,000,000 bytes, Chrome likely fails because it has actually >>>>> run out of memory (the next size it wants is 256MB or 512MB, and maybe >>>>> there isn't enough contiguous address space in the 32-bit process). And >>>>> failures without memory growth are not surprising, if the total used >>>>> memory >>>>> reached the current size of memory. >>>>> >>>>> Aside from that, the other failures are potentially surprising, which >>>>> leaves just IE9 behavior. Likely IE9 bugs - how about other versions of >>>>> IE, >>>>> and Firefox? If IE9 is the only one to fail, likely their bug. >>>>> >>>>> - Alon >>>>> >>>>> >>>>> On Tue, Feb 17, 2015 at 4:35 PM, Ishaan Venkatesan < >>>>> [email protected]> wrote: >>>>> >>>>>> Hi Alon, >>>>>> >>>>>> I was able to replicate the bug with a test case. Attached is the >>>>>> code for your reference. >>>>>> >>>>>> The code would build with Visual Studio 2012. When running WebApp >>>>>> project, you could enter the number of bytes you want to allocate, and a >>>>>> popup window would show up indicating whether the allocation (i.e. >>>>>> resizing >>>>>> an existing buffer) is successful or not. >>>>>> >>>>>> Running the software using a Surface Pro 3 with 8 G of memory & >>>>>> Windows 8 Pro OS, here are the test results I got: >>>>>> 1. Without "-s ALLOW_MEMORY_GROWTH=1", Chrome would allocate >>>>>> 8,000,000 bytes successfully, but would fail when allocating 9,000,000 >>>>>> bytes >>>>>> 2. Without "-s ALLOW_MEMORY_GROWTH=1", IE9 would allocate 8,000,000 >>>>>> bytes successfully, but would fail when allocating 9,000,000 bytes >>>>>> 3. With "-s ALLOW_MEMORY_GROWTH=1", Chrome would allocate 14,000,000 >>>>>> bytes successfully. >>>>>> 4. With "-s ALLOW_MEMORY_GROWTH=1", IE9 would would fail when >>>>>> allocating 14,000,000 bytes, although 9,000,000 bytes would work >>>>>> 5. With "-s ALLOW_MEMORY_GROWTH=1", Chrome would allocate >>>>>> 200,000,000 bytes successfully. But after trying to resize the buffer to >>>>>> 200,000,001 bytes, the call would fail. >>>>>> >>>>>> Please let me know if you need more information. Thanks Alon! >>>>>> >>>>>> On Monday, February 16, 2015 at 7:34:28 PM UTC-7, Ishaan Venkatesan >>>>>> wrote: >>>>>>> >>>>>>> Today I ran into the following exception after allocating an >>>>>>> std::vector<char> of size 718924 in C++. The exception said, >>>>>>> >>>>>>> "Cannot enlarge memory arrays. Either (1) compile with -s >>>>>>> TOTAL_MEMORY=X with X higher than the current value 16777216, (2) >>>>>>> compile >>>>>>> with ALLOW_MEMORY_GROWTH which adjusts the size at runtime but prevents >>>>>>> some optimizations" >>>>>>> >>>>>>> Although I was able to fix the exception by setting "-s >>>>>>> ALLOW_MEMORY_GROWTH=1" flag, it is still surprising that a memory block >>>>>>> of >>>>>>> less than 1M would cause the exception in the first place. In addition, >>>>>>> I >>>>>>> would prefer not to use ALLOW_MEMORY_GROWTH in order to maximize >>>>>>> performance. >>>>>>> >>>>>>> Interestingly, when I turned on "ALLOW_MEMORY_GROWTH" flag, the >>>>>>> Chrome browser was able to handle the large array correctly, but IE9 >>>>>>> threw >>>>>>> the same exception. >>>>>>> >>>>>>> Any thoughts on the cause of these problems? >>>>>>> >>>>>>> Thanks for your thoughts! >>>>>>> >>>>>> -- >>>>>> 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 [email protected]. >>>>>> 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 [email protected]. >>>> 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 [email protected] <javascript:>. >> 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
