https://osmocom.org/https://osmocom.org/favicon.ico?16647414092019-09-18T15:18:34ZOpen Source Mobile CommunicationsOsmoTRX - Bug #4181: osmo-trx-uhd: Crash during physical unplug of devicehttps://osmocom.org/issues/4181?journal_id=160162019-09-18T15:18:34Zpespin
<ul></ul><p>Probably thrown by <a class="external" href="https://github.com/EttusResearch/uhd/blob/b08352f267730ea417ec345cd90833a6746a1114/host/lib/transport/libusb1_base.cpp#L69">https://github.com/EttusResearch/uhd/blob/b08352f267730ea417ec345cd90833a6746a1114/host/lib/transport/libusb1_base.cpp#L69</a></p> OsmoTRX - Bug #4181: osmo-trx-uhd: Crash during physical unplug of devicehttps://osmocom.org/issues/4181?journal_id=160172019-09-18T16:20:42Zpespin
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>Closed</i></li></ul><p>As far as I understand, the UHD code is run in a separate thread created by UHD's task::make: <a class="external" href="https://files.ettus.com/manual/classuhd_1_1task.html">https://files.ettus.com/manual/classuhd_1_1task.html</a><br /><pre>
task_handler = task::make(
boost::bind(&libusb_session_impl::libusb_event_handler_task, this, _context));
</pre></p>
<p>As a result, we have no access to catching c++ exceptions from that thread, and the c++ exception ends up calling abort() which sends SIGABRT to the process ("signal 6 received").</p>
<p>The current osmo-trx signal handler:<br /><pre>
static void sig_handler(int signo)
{
if (gshutdown)
/* We are in the middle of shutdown process, avoid any kind of extra
action like printing */
return;
fprintf(stderr, "signal %d received\n", signo);
switch (signo) {
case SIGINT:
case SIGTERM:
fprintf(stderr, "shutting down\n");
gshutdown = true;
break;
case SIGABRT:
case SIGUSR1:
talloc_report(tall_trx_ctx, stderr);
talloc_report_full(tall_trx_ctx, stderr);
break;
case SIGUSR2:
talloc_report_full(tall_trx_ctx, stderr);
break;
case SIGHUP:
log_targets_reopen();
default:
break;
}
}
</pre></p>
<p>Unfortunately there doesn't seem to be a way to handle things fine and shut down properly in this scenario (abort called). According to POSIX:<br /><pre>
The abort() function shall cause abnormal process termination to occur, unless the signal SIGABRT is being caught and the signal handler does not return.
</pre></p>
<p>I don't see how we can avoid the signal handler stopping (other than by stopping/cancelling the thread or making it block forever, specially since we use signalfd so the process executing the abort signal is probably the main one. It's probably better to let it continue so a core dump is generated (not sure if it makes much sense though since anyway other threads keep runing...).</p>
<p>So I'm closing the ticket.</p>