"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]> 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]. > 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.
