Thank you received: 62
help on indi wiringPi gpio crash
Please Log in or Create an account to join the conversation.
Topic Author
I will try to get a version close to yours and recompile and see if thats the cause.
Ok, this is really old ...Magnus_e wrote:
gcc version 4.9.2
I will try to get a version close to yours and recompile and see if thats the cause.
Please Log in or Create an account to join the conversation.
Topic Author
Ok, with 2017-07-05-raspbian-jessie.img (gcc-4.9.2) indi_wiringPi_gpio works.
Magnus_e I bet if you update your gcc or use any recent distro for Raspberry I am sure it will
crash on your system too.
It seems something changed from gcc-4.9.x to gcc-?? that made your driver unusable.
If I stay on gcc-4.9.2 (jessie) I think it will be only a matter of time until something indi related requires >gcc-4.9.x
and I will be back at this issue.
I think the issue has nothing to do with the systeminfo tabs, I removed that code completely but the issue persists.
It must be something in wiringpi_gpio.cpp.
I will try to take a look at valgrind, maybe I can get a hint where the problem originates from but I currently only get some kind of restarting loop if I try it with:and if I connect kstars it somehow never reaches the point where the driver gets fully initialized.
Magnus_e I bet if you update your gcc or use any recent distro for Raspberry I am sure it will
crash on your system too.
It seems something changed from gcc-4.9.x to gcc-?? that made your driver unusable.
If I stay on gcc-4.9.2 (jessie) I think it will be only a matter of time until something indi related requires >gcc-4.9.x
and I will be back at this issue.
I think the issue has nothing to do with the systeminfo tabs, I removed that code completely but the issue persists.
It must be something in wiringpi_gpio.cpp.
I will try to take a look at valgrind, maybe I can get a hint where the problem originates from but I currently only get some kind of restarting loop if I try it with:
valgrind --trace-children=yes indiserver -v indi_simulator_telescope indi_simulator_ccd indi_wiringpi_gpioPlease Log in or Create an account to join the conversation.
First of all, thanks for being so patient and locating the issue.
My servers are remote, so I do not do any dist upgrades remotely.
For me the imaging seson is pretty much over at april 22. as there is no more true nighttime here in at my latitude. I will try to image the next full moon, but then there will be no more imaging before ~ August 22.
I have several things to fix / upgrade in my obsy, and one of them is using wiringpi_gpio to sense roof state, and telescope parking in an attemp to move to a closed loop robotic observatory
I will then collect my servers from the remote location, take them home, and get everything up to code.
For now all of INDI works with the setup I have, but as you say it's likely for issues to arise eventually.
My servers are remote, so I do not do any dist upgrades remotely.
For me the imaging seson is pretty much over at april 22. as there is no more true nighttime here in at my latitude. I will try to image the next full moon, but then there will be no more imaging before ~ August 22.
I have several things to fix / upgrade in my obsy, and one of them is using wiringpi_gpio to sense roof state, and telescope parking in an attemp to move to a closed loop robotic observatory
I will then collect my servers from the remote location, take them home, and get everything up to code.
For now all of INDI works with the setup I have, but as you say it's likely for issues to arise eventually.
Please Log in or Create an account to join the conversation.
Topic Author
Ok, thanks Magnus_e.
In the meantime just out of curiosity and for personal pleasure
I am playing with valgrind and it found some issues:
#valgrind --leak-check=full --show-leak-kinds=all --trace-children=yes --track-origins=yes indiserver indi_wiringpi_gpio
full log:
pastebin.com/raw/X4Mruu6F
PS. Line Numbers refer to my cleaned code of indi_wiringpi_gpio (github.com/pauledd/indi_wiringpi_gpio_clean)
In the meantime just out of curiosity and for personal pleasure
I am playing with valgrind and it found some issues:#valgrind --leak-check=full --show-leak-kinds=all --trace-children=yes --track-origins=yes indiserver indi_wiringpi_gpio
...
2018-04-10T07:36:51: Driver indi_wiringpi_gpio: ==4988== Conditional jump or move depends on uninitialised value(s)
2018-04-10T07:36:51: Driver indi_wiringpi_gpio: ==4988== Uninitialised value was created by a heap allocation
2018-04-10T07:36:53: Driver indi_wiringpi_gpio: ==4988== Invalid read of size 8PS. Line Numbers refer to my cleaned code of indi_wiringpi_gpio (github.com/pauledd/indi_wiringpi_gpio_clean)
Please Log in or Create an account to join the conversation.
Topic Author
I maybe made a bit of progress.
This "Uninitialised value was created by a heap allocation" (wiringpi_gpio.cpp) seems to be related to the part
in the updateProperties() function where you test for NULL:My thought was that "InputDigitalLP->lp" and "OutputDigitalSP->sp" needs to be initialized with something...
So I assigned NULL to it right after its creation in the "WiringPiGPIO::WiringPiGPIO()" constructor:
I really dont know If this is the right way to do it but a first tests with the new code show normal behaviour of the driver (compiled with gcc-6.x).
I can set gpio's, switch them, and save them successfully
.
I will report back if there is any new fail.
This "Uninitialised value was created by a heap allocation" (wiringpi_gpio.cpp) seems to be related to the part
in the updateProperties() function where you test for NULL:
if (InputDigitalLP[i]->lp != NULL)
defineLight(InputDigitalLP[i]);
if (OutputDigitalSP[i]->sp != NULL)
defineSwitch(OutputDigitalSP[i]);So I assigned NULL to it right after its creation in the "WiringPiGPIO::WiringPiGPIO()" constructor:
WiringPiGPIO::WiringPiGPIO()
{
for (int i = 0; i < NUMBER_OF_PINS; i++)
{
InputDigitalLP[i] = new ILightVectorProperty;
OutputDigitalSP[i] = new ISwitchVectorProperty;
// added
InputDigitalLP[i]->lp = NULL;
OutputDigitalSP[i]->sp = NULL;
//
}
OutputPWMNP = new INumberVectorProperty;
setVersion(0,1);
setDriverInterface(AUX_INTERFACE);
}I really dont know If this is the right way to do it but a first tests with the new code show normal behaviour of the driver (compiled with gcc-6.x).
I can set gpio's, switch them, and save them successfully
.I will report back if there is any new fail.
Please Log in or Create an account to join the conversation.
Please Log in or Create an account to join the conversation.
Topic Author
So far ... it seems to work, in my opinion you can close the issue on github.
Just some things in your code I want to mention :
- maybe change NULL to nullptr?
- maybe change from -std=c++0x to c++11?
indi_wiringpi_gpio
- I always have to add this crypt flag to CmakeLists.txt
( github.com/magnue/indi_wiringpi_gpio/iss...suecomment-379486642 )
indi_servoblaster_cap
- you should check to include <cstring> as I get compiler errors without it (gcc-6.x)
- I had to remove the code in "ServoBlasterCap::EnableLightBox" that checks if cap is parked.
I cannot activate the light of my flatfield-dustcover if closed but I have to, to make flats, maybe you can implement
some kind of checkbox to disable this check.
- maybe enable issues page on github for that repo so than I can bother you with my problems there
Just some things in your code I want to mention :
- maybe change NULL to nullptr?
- maybe change from -std=c++0x to c++11?
indi_wiringpi_gpio
- I always have to add this crypt flag to CmakeLists.txt
( github.com/magnue/indi_wiringpi_gpio/iss...suecomment-379486642 )
indi_servoblaster_cap
- you should check to include <cstring> as I get compiler errors without it (gcc-6.x)
- I had to remove the code in "ServoBlasterCap::EnableLightBox" that checks if cap is parked.
I cannot activate the light of my flatfield-dustcover if closed but I have to, to make flats, maybe you can implement
some kind of checkbox to disable this check.
- maybe enable issues page on github for that repo so than I can bother you with my problems there
Please Log in or Create an account to join the conversation.
Done, done and done.
The code that limits the dust cover position for the light source was removed on August 17th 2017
The code that limits the dust cover position for the light source was removed on August 17th 2017
Please Log in or Create an account to join the conversation.
Topic Author
cheer!
All systems go! Time to haul my scope back on balcony
must have missed that in my fork.was removed on August 17th 2017
All systems go! Time to haul my scope back on balcony
Please Log in or Create an account to join the conversation.
Time to create page: 0.334 seconds