I was imaging and PHD2 got into a state where it seemed to think that it was
exposing, but no exposure had been scheduled. I could neither stop nor continue
guiding and had to terminate PHD2.
Looking at the logs, there is a line indicating entry into Star::Find with no
corresponding log entry indicating exit from the function!
00:17:02.679 00.000 8320 Star::Find(0x02CFD740, 15, 120, 562)
00:17:02.714 00.035 8320 read socket command 10
00:17:02.714 00.000 8320 processing socket request REQDIST
00:17:02.714 00.000 8320 SOCKSVR: Sending pixel error of 2.55
00:17:02.714 00.000 8320 Sending socket respose 255 (0xff)
All log entries for entry into Star::Find are expected to have a matching line
for exit from the function (or an error message), for example:
00:17:00.011 00.001 8320 Star::Find(0x02CFD740, 15, 120, 562)
00:17:00.011 00.000 8320 Star::Find returns 0, X=120.00, Y=562.00
I hypothesize an illegal memory access and Windows SEH somehow allowing
wxWidgets to recover without crashing but being left in the inconsistent state
(looping active but no exposure scheduled).
Inspection of Star::Find shows that there is indeed an opportunity for
accessing memory outside the image array. The first iteration ("rough guess")
locates the maximum within the search region and has correct bounds checking.
However, the second iteration ("hone in") uses a new search region centered on
the position determined by the first iteration, and there is NO BOUNDS CHECK
for the second iteration! If the star has drifted to the edge of the frame, the
second iteration can access memory outside the bounds of the image array.
This can be reproduced in the simulator: use manual guide to move a star near
the bottom edge and start guiding. Open the cam dialog and turn on clouds.
After a few seconds PHD2 gets stuck.
Original issue reported on code.google.com by andy.gal...@gmail.com on 3 Jan 2014 at 8:24
Original issue reported on code.google.com by
andy.gal...@gmail.com
on 3 Jan 2014 at 8:24