In my tests if I add an argument < 0 (in fact, < 1), the stack trace of the RTE comes out with "at flash.display::BitmapData/ctor()", as I mentioned. So I assumed that when the stack trace doesn't include the ctor() function (which I guess is the C constructor) the cause is different (most likely memory issues?)
On 15 January 2015 at 14:36, Alex Harui <aha...@adobe.com> wrote: > I think the most common is that the dimensions asked for include numbers < > 0. > > On 1/15/15, 1:22 AM, "Mihai Chira" <mih...@apache.org> wrote: > >>Bump. No ideas? >> >>On 6 January 2015 at 11:34, Mihai Chira <mihai.ch...@gmail.com> wrote: >>> In our application we've been getting a bunch of reports of >>> "ArgumentError: Error #2015 / at flash.display::BitmapData() / at >>> ...etc." errors - thrown both in our custom code and in the SDK code. >>> (The applications are AIR and run on PCs and Macs - non-mobile only.) >>> >>> Am I right in assuming that it's a case of the operating system >>> refusing to allocate the memory required for the new BitmapData >>> object? Could it be down to something else? >>> >>> PS: if the arguments to the BitmapData() constructor are wrong (either >>> < 1, NaN, or their product is too large to allocate), the stack trace >>> is "ArgumentError: Error #2015: Invalid BitmapData. / at >>> flash.display::BitmapData/ctor() / at flash.display::BitmapData() / at >>> ...etc.", so I imagine it's unrelated? >