2015r1 having "exception of type std::bad_alloc: std::bad_alloc" errors

Targets Web
1

Hi there,
Since I’ve switched to 2015r1 I 'm getting this kind of errors, mostly when, while debugging I left the web app waiting with no user action for a while.

11:07:03 AM --- Proto HUI P2Flow Launched 11:07:04 AM --- Feb 19 11:07:04 macmini.local Proto HUI P2Flow.debug[17228] <Warning>: @--#000001 > Session.Open> Opening #A4A2B15CB8D3D81E78A522457649A3B3 (IP: 127.0.0.1 ) 11:09:53 AM --- Proto HUI P2Flow.debug(17228,0xb0093000) malloc: *** mach_vm_map(size=55574528) failed (error code=3) 11:10:02 AM --- *** error: can't allocate region *** set a breakpoint in malloc_error_break to debug 11:10:33 AM --- libc++abi.dylib: terminating with uncaught exception of type std::bad_alloc: std::bad_alloc 11:12:23 AM --- Process Completed. 11:12:24 AM --- Proto HUI P2Flow Ended
It’s on Yosemite 10.10.2
Anybody else seeing this error?

Eric.

2

do you have a crash report from this?
Maybe it shows where the exception is not catched.

Also monitor memory usage of app. Maybe it uses over 2 GB of memory?

3

Here is an excerpt of the crash report:

[code]Crashed Thread: 4

Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000

Application Specific Information:
abort() called
terminating with uncaught exception of type std::bad_alloc: std::bad_alloc
[…]
Thread 4 Crashed:
0 libsystem_kernel.dylib 0x94cf069a __pthread_kill + 10
1 libsystem_pthread.dylib 0x98eccf19 pthread_kill + 101
2 libsystem_c.dylib 0x96e63eee abort + 156
3 libc++abi.dylib 0x9ae262f9 abort_message + 169
4 libc++abi.dylib 0x9ae49483 default_terminate_handler() + 272
5 libc++abi.dylib 0x9ae46ac0 std::__terminate(void (*)()) + 14
6 libc++abi.dylib 0x9ae464db __cxa_throw + 122
7 libc++.1.dylib 0x952c1ac6 operator new(unsigned long) + 102
8 rbframework.dylib 0x004d44d5 0x484000 + 328917
9 Proto HUI P2Flow.debug 0x00215d3c WebMenuItem.Append%%oo + 280
10 Proto HUI P2Flow.debug 0x0034188a ContainerCardsList.ContainerCardsList.BuildCameramanPickerMenu%o%o<ContainerCardsList.ContainerCardsList> + 1615
11 Proto HUI P2Flow.debug 0x00341c85 ContainerCardsList.ContainerCardsList.BuildContextualMenu%o%o<ContainerCardsList.ContainerCardsList> + 255
12 Proto HUI P2Flow.debug 0x00341100 ContainerCardsList.ContainerCardsList.Event_Shown%%o<ContainerCardsList.ContainerCardsList> + 661
13 Proto HUI P2Flow.debug 0x00191772 WebView._DoShownEvent%%o + 345
14 Proto HUI P2Flow.debug 0x0018c1a4 WebView.Event_Shown%%o + 62
15 Proto HUI P2Flow.debug 0x00251f62 WebControl._ExecuteEvent%b%osA1v + 17502
16 Proto HUI P2Flow.debug 0x001b4d1f WebContainer._ExecuteEvent%b%osA1v + 217
17 Proto HUI P2Flow.debug 0x0024d958 WebControl.!_ExecuteEvent%b%ssA1v + 270
18 Proto HUI P2Flow.debug 0x0011d2d4 WebSession._HandleEvent%%oso<HTTPServer.HTTPRequestContext> + 2920
19 Proto HUI P2Flow.debug 0x0011e6bc WebSession._HandleRequest%i4%oso<HTTPServer.HTTPRequestContext> + 3562
20 Proto HUI P2Flow.debug 0x000fb09f WebApplication._HandleHTTPRequest%%oo<HTTPServer.HTTPRequestContext> + 35324
21 Proto HUI P2Flow.debug 0x000ac378 HTTPServer.HTTPRequestThread.Event_Run%%o<HTTPServer.HTTPRequestThread> + 428
22 rbframework.dylib 0x004ad463 0x484000 + 169059
23 libsystem_pthread.dylib 0x98ecae13 _pthread_body + 138
24 libsystem_pthread.dylib 0x98ecad89 _pthread_start + 162
25 libsystem_pthread.dylib 0x98ec8e52 thread_start + 34[/code]
And I’ll monitor the usage of memory.

Eric.

4

I would love to see that function raise an OutOfMemoryException instead of crashing here.

But maybe app is simply leaking memory until it crashes.

5

Yep. It was a missing RecordSet.MoveNext call creating and endless loop filling up the memory used by the app up to more than 3GB until it crashes.
Yet, I agree with you: It should raise an OutOfMemoryException.
Reported as <https://xojo.com/issue/38245>

Eric.

6

I doubt this would make sense. I’ve learned to not try to catch a bad_alloc error in C++ because you won’t be able to do anything - you’ve run out of memory and there is literally nothing you can do.

7

There a small number of scenarios where recovering from std::bad_alloc makes sense. Typically they’re in places where you’re allocating a huge chunk of memory in one go and failing still leaves you with plenty of memory to continue. For example, creating a gigantic image.

8

What about the framework allocating a “rainy day fund” when the app starts (a memory block which is not used, but is just there to take up some space.) If an OOM error occurs, the framework frees that block immediately, at which point the app should have enough memory left to fail more gracefully?

9

oh, there is a feedback case for all that stuff with a couple of ideas.

I still think that the most common cases for such an error should be covered with OutOfMemoryExceptions like string concat.

10

<https://xojo.com/issue/12072> or <https://xojo.com/issue/33025> perhaps?

11

yes, 33025 is more detailed about specific things where Xojo apps love to crash.
12072 is the more general case.

12

I’m breaking my head around this issue for a few days… it has worked fine into one of my webapp for months… and from 2015 it crasches… Today I solved my problem… I move the “dim menu as new webmenuitem…” from “open” to “shown” event and it works!
I hope this can help you too…