# Could we support unwinding from OOM, at least for collections?

**URL:** <https://internals.rust-lang.org/t/could-we-support-unwinding-from-oom-at-least-for-collections/3673>\
**Category:** libs\
**Created:** [July 9, 2016, 5:17am UTC](https://internals.rust-lang.org/t/could-we-support-unwinding-from-oom-at-least-for-collections/3673 "2016-07-09T05:17:14Z")\
**Posts on this page:** 1\
**Showing post:** 21

<div class="post-metadata">

**Author:** ![lilith](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/lilith/32/11080_2.png) [@lilith](https://internals.rust-lang.org/u/lilith)\
**Post date:** [August 28, 2016, 11:36pm UTC](https://internals.rust-lang.org/t/could-we-support-unwinding-from-oom-at-least-for-collections/3673/21 "2016-08-28T23:36:06Z")

</div>

I’m running x86\_64, Ubuntu 14.04. malloc fails quite regularly for me. Rumours of overcommit seem greatly exaggerated.

SIGILL is easily generated by:

```
let b = vec![0;30 * 1024 * 1024 * 1024];

```

While, ideally, rust would expose fallible calls like malloc via Result\<\> types, those APIs look very far away.

I started porting an in-development C image processing server to Rust after hearing `catch_unwind` was stabilized. Then I discovered that the crowds were shouting for all OOM situations to abort instead of panic. I found this strange, as small mallocs will often succeed after large mallocs fail. And large mallocs are quite important to my use case - and my use case permits many strategies for backing off large malloc requests if they fail.

So while my current C code gracefully handles all allocation failures, I cannot seem to accomplish the same in Rust - and real problems arise quite quickly.

---

_[View the full topic](https://internals.rust-lang.org/t/could-we-support-unwinding-from-oom-at-least-for-collections/3673)._