5 ms·

I would love to see what's really causing this bug. We read so many times over the weekend to either reboot or just run that date command - but nobody is tellin

by pilif 14y ago

I would love to see what's really causing this bug. We read so many times over the weekend to either reboot or just run that date command - but nobody is telling us what's causing the problem. Also, seeing that other threaded applications had similar problems, I doubt this is a java issue - more likely a pthread, glibc or even kernel issue

gaius 14y ago
There is a good explanation here: http://serverfault.com/q/403732/58037 http://serverfault.com/q/403732/58037
- agwa 14y ago
  That's predominantly about the kernel crash, not the high-CPU futex issue. One of the most maddening things about this is that there have been several different issues related to leap seconds on Linux, making it all the harder to get information.
altxwally 14y ago
The patch that was shared on the lkml shows some insight on what is causing the issue. https://lkml.org/lkml/2012/7/1/27 https://lkml.org/lkml/2012/7/1/27 Apparently the issues might be due "to the leapsecond being added without calling clock_was_set() to notify the hrtimer subsystem of the change", a possible fix being to patch kernel/time/timekeeping.c to be leapsecond aware.
ajays 14y ago
This seems like the best explanation I've found so far: https://lkml.org/lkml/2012/7/1/203 https://lkml.org/lkml/2012/7/1/203
- pilif 14y ago
  Agreed. Also it clearly accounts for the futex related load issues and it even gives nice and readable C code to see the problem happening. This explains it for me. Thanks a lot for the pointer.
xxpor 14y ago
A good explanation from Reddit: http://www.reddit.com/r/programming/comments/vxmf7/time_arithmetic_you_win_again/c58lkmx http://www.reddit.com/r/programming/comments/vxmf7/time_arit...