[jira] [Resolved] (IMPALA-4631) plan-fragment-executor.cc:518] Check failed: other_time <= total_time (25999394 vs. 25999393)

["Tim Armstrong (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/IMPALA-4631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tim Armstrong resolved IMPALA-4631.
-----------------------------------
    Resolution: Won't Fix

This was only ever seen infrequently on a old hypervisor/kernel combination. I think we probably just need to avoid this by upgrading those...

{noformat}
OS version: Linux version 2.6.32-358.14.1.el6.centos.plus.x86_64 (mockbuild@c6b9.bsys.dev.centos.org) (gcc version 4.4.6 20120305 (Red Hat 4.4.6-4) (GCC) ) #1 SMP Tue Jul 16 21:33:24 UTC 2013
Clock: clocksource: 'xen', clockid_t: CLOCK_MONOTONIC_COARSE
{noformat}

> 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: Daniel 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
(v8.3.4#803005)