[lttng-dev] liburcu's assertion failed when cannot allocate memory

[Mathieu Desnoyers]

----- On Jun 15, 2017, at 9:02 AM, Denis Yevgenyevich <denis.yevgenyevich at gmail.com> wrote: 

> My memory-constrained application dumps core saying

> Assertion failed: (!ret), function _cds_wfcq_init, file
> ./urcu/static/wfcqueue.h, line 107.
> Abort

> The function was called from the call_rcu thread, my app does not call wfcqueue
> directly.

> My operating system is FreeBSD-10.3, you won't reproduce the failure in Linux.
> Apparently developers assumed that pthread_mutex_init cannot fail. This
> assumption is ok for Linux, but not so with FreeBSD, which allocates mutexes
> with calloc.

> Could you please add proper error handling so that (at least) call_rcu threads
> could cope with memory allocation failures?

> Cheers...

Hi, 

There are interfaces in liburcu such as rcu_read_lock and call_rcu for which we 
don't want to impose error-handling to users. And in a vast majority of applications, 
aborting on memory allocation failure appears to be acceptable. So let's see how 
we could allow special use-cases like yours to be fulfilled without making the API 
needlessly complex. 

One possibility would be to add optional handling of out-of-memory scenarios 
through handlers registered by the application. An application could then use 
setjmp before calling liburcu functions and longjmp from the registered handler 
to recover from those errors. Of course, liburcu would have to ensure it's undoing 
its side-effects before invoking the application-provided out-of-memory handler. 

Thoughts ? 

Thanks, 

Mathieu 

> _______________________________________________
> lttng-dev mailing list
> lttng-dev at lists.lttng.org
> https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

-- 
Mathieu Desnoyers 
EfficiOS Inc. 
http://www.efficios.com 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.lttng.org/pipermail/lttng-dev/attachments/20170623/dfaafc75/attachment.html>