[ https://issues.apache.org/jira/browse/IMPALA-4631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16823331#comment-16823331 ]
Michael Ho commented on IMPALA-4631: ------------------------------------ The problem still occurs after loosening the DCHECK: {noformat} F0420 03:50:03.056339 2817 fragment-instance-state.cc:330] Check failed: other_time <= total_time + 3 (646003282 vs. 646003278) {noformat} Makes me wonder if there is a genuine bug here. > plan-fragment-executor.cc:518] Check failed: other_time <= total_time > (25999394 vs. 25999393) > --------------------------------------------------------------------------------------------- > > Key: IMPALA-4631 > URL: https://issues.apache.org/jira/browse/IMPALA-4631 > Project: IMPALA > Issue Type: Bug > Components: Backend > Affects Versions: Impala 2.8.0 > Reporter: Dan Hecht > Assignee: Dan Hecht > Priority: Major > Labels: flaky > > This dcheck occasionally fires: > {code} > impalad.FATAL:F1201 22:35:58.617157 30293 plan-fragment-executor.cc:518] > Check failed: other_time <= total_time (25999394 vs. 25999393) > {code} > I suspect the problem is with using floating point operations in places like > this: > {code} > timespec ts; > clock_gettime(OsInfo::fast_clock(), &ts); > return ts.tv_sec * 1e9 + ts.tv_nsec; > {code} > and because floating point doesn't distribute, and we can end up with > {noformat} c * (a + b) < c * a + c * b {noformat} which is effectively what > the dcheck does. -- This message was sent by Atlassian JIRA (v7.6.3#76005) --------------------------------------------------------------------- To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org