Actions
Bug #46024
closedlarger osd_scrub_max_preemptions values cause Floating point exception
% Done:
0%
Source:
Community (dev)
Tags:
Backport:
octopus,nautilus
Regression:
No
Severity:
3 - minor
Reviewed:
Affected Versions:
ceph-qa-suite:
Component(RADOS):
Pull request ID:
Crash signature (v1):
Crash signature (v2):
Description
A non-default large osd_scrub_max_preemptions value (e.g., 32) would cause scrubber.preempt_divisor underflow and hence the Floating point exception（AKA the dreaded “divide by zero error”）
0> 2020-06-15 22:02:24.249 7f07e1cf5700 -1 *** Caught signal (Floating point exception) **
in thread 7f07e1cf5700 thread_name:tp_osd_tp
ceph version 14.2.9-1-809-g55846e895db (55846e895db09a236ac292b68b7c141a555844ca) nautilus (stable)
1: (()+0xf5d0) [0x7f080545b5d0]
2: (PG::chunky_scrub(ThreadPool::TPHandle&)+0x78e) [0x55c9e8fc864e]
3: (PG::scrub(unsigned int, ThreadPool::TPHandle&)+0x4bb) [0x55c9e8fcaa2b]
4: (PGScrub::run(OSD*, OSDShard*, boost::intrusive_ptr<PG>&, ThreadPool::TPHandle&)+0x12) [0x55c9e916e232]
5: (OSD::ShardedOpWQ::_process(unsigned int, ceph::heartbeat_handle_d*)+0x1505) [0x55c9e8efeef5]
6: (ShardedThreadPool::shardedthreadpool_worker(unsigned int)+0x5b6) [0x55c9e94a4c16]
7: (ShardedThreadPool::WorkThreadSharded::entry()+0x10) [0x55c9e94a6d50]
8: (()+0x7dd5) [0x7f0805453dd5]
9: (clone()+0x6d) [0x7f080431bead]
NOTE: a copy of the executable, or `objdump -rdS <executable>` is needed to interpret this.
Updated by Neha Ojha almost 4 years ago
- Status changed from New to Fix Under Review
Updated by xie xingguo almost 4 years ago
- Status changed from Fix Under Review to Pending Backport
- Backport set to octopus,nautilus
Updated by Nathan Cutler almost 4 years ago
- Copied to Backport #46261: octopus: larger osd_scrub_max_preemptions values cause Floating point exception added
Updated by Nathan Cutler almost 4 years ago
- Copied to Backport #46262: nautilus: larger osd_scrub_max_preemptions values cause Floating point exception added
Updated by Nathan Cutler over 3 years ago
- Status changed from Pending Backport to Resolved
While running with --resolve-parent, the script "backport-create-issue" noticed that all backports of this issue are in status "Resolved" or "Rejected".
Actions