https://bugs.kde.org/show_bug.cgi?id=515021
Bug ID: 515021
Summary: EKOS crash: division by zero in filterFocusStars
Classification: Applications
Product: kstars
Version First 3.6.2
Reported In:
Platform: Debian stable
OS: Linux
Status: REPORTED
Severity: crash
Priority: NOR
Component: general
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: ---
SUMMARY
Ekos crashed on me twice in the recent week, on two nights. Messages in journal
on the first occasion were:
```
sty 18 21:21:06 tinkpad2 org.kde.kstars.desktop[51962]:
org.kde.kstars.ekos.focus: Failed to extract any stars.
sty 18 21:21:06 tinkpad2 kernel: traps: kstars[51962] trap divide error
ip:55fd2b5d99c1 sp:7fff67a40050 error:0 in kstars[8289c1,55fd2aebc000+bce000]
sty 18 21:21:06 tinkpad2 systemd[2505]: app-gnome-org.kde.kstars-51962.scope:
Consumed 8h 57min 19.956s CPU time, 26G memory peak, 429M memory swap peak.
```
The second time it was similar, but some addresses were different:
```
sty 22 03:23:41 tinkpad2 kernel: traps: kstars[2626825] trap divide error
ip:564d62a929c1 sp:7ffdfd4bb460 error:0 in kstars[8289c1,564d62375000+bce000]
```
STEPS TO REPRODUCE
1. Run the scheduler on some objects
OBSERVED RESULT
Realize in the morning that kstars is gone, and your telescope was idle for a
big chunk of the night :-(
EXPECTED RESULT
Lots of nice subexposures :-)
SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Debian stable
Qt Version: irrelevant
ADDITIONAL INFORMATION
Here is a description of how I found the problematic instruction, hope it will
be useful to others.
Due to address space layout randomization and lack of core file, the IP value
from the crash message was not enough to find the responsible line of code.
```
(gdb) info line *0x55fd2b5d99c1
No line number information available for address 0x55fd2b5d99c1
```
When I load kstars under gdb and check the maps file, the addresses are
different each time, for example:
```
$ cat /proc/3151239/maps|grep kstars
555555554000-55555565f000 r--p 00000000 fd:01 22345780
/usr/bin/kstars
55555565f000-55555622d000 r-xp 0010b000 fd:01 22345780
/usr/bin/kstars
55555622d000-555556682000 r--p 00cd9000 fd:01 22345780
/usr/bin/kstars
555556682000-5555566d1000 r--p 0112e000 fd:01 22345780
/usr/bin/kstars
5555566d1000-5555566d3000 rw-p 0117d000 fd:01 22345780
/usr/bin/kstars
```
However I noticed that:
- the difference between the instruction pointer ("ip:") value and the VMA
start address (the number after comma in the last part of the message, i.e.
55fd2aebc000 in kstars[8289c1,55fd2aebc000+bce000]) is the same in both cases:
0x71D9C1, so this was likely the offset of IP in this VMA
- the size of the VMA (the last number in the message) matches the size of the
second memory area in the maps file (the executable one, i.e. r-xp).
- adding the base of the second area for the process running under GDB to the
offset: 55555565f000+71D9C1 = 555555D7C9C1 is the correct IP of the problematic
instruction:
```
(gdb) info line *0x555555D7C9C1
Line 131 of "./kstars/ekos/focus/focusstars.cpp" starts at address
0x555555d7c9c0 <_ZNK4Ekos10FocusStars9commonHFRERKS0_PdS3_+672> and ends at
0x555555d7c9c5 <_ZNK4Ekos10FocusStars9commonHFRERKS0_PdS3_+677>.
```
It's this line:
https://invent.kde.org/education/kstars/-/blob/master/kstars/ekos/focus/focusstars.cpp?ref_type=heads#L131
```
const int seed = rand() % size1;
```
Apparently, if the "stars1" collection is empty (e.g. due to an obstruction or
clouds), then "size1" will be zero, and the modulo division will cause a fatal
trap.
--
You are receiving this mail because:
You are watching all bug changes.
