search

so-90prime / 90prime

General repo for everything related to 90Prime (docs, diagrams, thoughts)
2 stars 0 forks source link

INDI code on bart is buggered after OS update. #37

Closed dsand closed 2 years ago

dsand commented 2 years ago

quotes from Phil. Do not want to lose this thread.

Here's what happened AFAIK: CJ called me this morning to ask how to start the bokGalilIndiDriver so I went though the instructions with him. It ran. Since I'm not familiar enough yet with your GUI, I said he could use Xephem and that's what he did. After lunch he called again saying the driver wasn't working. At the time he mentioned a reboot so I logged in an tried to restart the driver myself but, sure enough, it crashed. At that point, the upgrade was mentioned so it's clear the upgrade broke something as the driver code didn't change between this morning and this afternoon.

To add further insult to injury, CJ (accidentally I'm sure) deleted the /usr/local/indi tree that I used to build INDI 1.9.1. I might have a copy on my laptop which is in my office. Trying a fresh install with 1.9.3 failed as there is a bug in the INDI code which stops the build.

dsand commented 2 years ago

Update. @pndaly thinks this could be a gclib issue and will investigate.

pndaly commented 2 years ago

OK, after the Xmas break I took a look at the code. I think gclib is exonerated as things are now working OK with the independent Galil_DMC_22x0_CLI code (which has gclib dependencies only and is nothing to do with INDI). I rebuilt the INDI driver and it still failed so I dug into the code. Since the failure is a 'child process termination', it smacked of a memory violation. I isolated the line(s) where is was failing:

_gfiltn = (int)round(tcp_val.lv.gfiltn); gfilter_changeS[_gfiltn - 1].s = ISS_ON;

So, the problem is that gfiltn initializes to 99999.0 and the array specifies indexes 0-6. Fixing that with:

if (_gfiltn>=0 && _gfiltn<=BOK_GFILTERS) { gfilter_changeS[_gfiltn - 1].s = ISS_ON; // Subtract one since zero based }

and re-building the driver makes everything work again. There may be other instances like this so I'll check the code.

In short, the only thing I can think of (since the source code didn't change before/after the 'apt update' that caused the problem), is that the GCC compiler is now much more strict in run-time and causes the segmentation fault.

Clear as mud?