
<html><body><div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; color: #000000"><div><br></div><span id="zwchr" data-marker="__DIVIDER__">----- On Jun 15, 2017, at 9:02 AM, Denis Yevgenyevich <denis.yevgenyevich@gmail.com> wrote:<br></span><div data-marker="__QUOTED_TEXT__"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><div dir="ltr"><div><div><div>My memory-constrained application dumps core saying<br><br>Assertion failed: (!ret), function _cds_wfcq_init, file ./urcu/static/wfcqueue.h, line 107.<br>Abort<br><br></div><div>The function was called from the call_rcu thread, my app does not call wfcqueue directly.<br></div><div><br>My operating system is FreeBSD-10.3, you won't reproduce the failure in Linux.<br></div> 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.<br><br></div>Could you please add proper error handling so that (at least) call_rcu threads could cope with memory allocation failures?<br><br></div>Cheers...</div></blockquote><div><br></div><div>Hi,<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>There are interfaces in liburcu such as rcu_read_lock and call_rcu for which we<br data-mce-bogus="1"></div><div>don't want to impose error-handling to users. And in a vast majority of applications,</div><div>aborting on memory allocation failure appears to be acceptable. So let's see how</div><div>we could allow special use-cases like yours to be fulfilled without making the API</div><div>needlessly complex.<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>One possibility would be to add optional handling of out-of-memory scenarios<br data-mce-bogus="1"></div><div>through handlers registered by the application. An application could then use</div><div>setjmp before calling liburcu functions and longjmp from the registered handler<br data-mce-bogus="1"></div><div>to recover from those errors. Of course, liburcu would have to ensure it's undoing<br data-mce-bogus="1"></div><div>its side-effects before invoking the application-provided out-of-memory handler.<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>Thoughts ?<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>Thanks,<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>Mathieu<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><div dir="ltr"><br></div><br>_______________________________________________<br>lttng-dev mailing list<br>lttng-dev@lists.lttng.org<br>https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev<br></blockquote></div><br><div data-marker="__SIG_POST__">-- <br></div><div>Mathieu Desnoyers<br>EfficiOS Inc.<br>http://www.efficios.com</div></div></body></html>