OK - I have it figured out.? ?It was not a traditional "Memory Leak".? However it was a 'Memory Eater" (a subtle difference)? ?It only ate Memory during sending CW.? It was not a CPU resource issue - there is plenty of CPU to run manual CW with the zBITX ( I can't speak for any other mode ).
?
I had been saying that I have been running my zBITX in Receive Mode.? If I had done exactly that, then mine would have run for hours and hours, much as Gordon's zBITX does.? ?In reality, I have been sending a little CW from time to time, just to check and see if it is still healthy and responsive.? So, for me, it has been maybe 90-95% listening and 5-10% sending CW.
?
Whenever you power up your zBITX, a script called start.sh automatically runs.? ?I'm no linux guru, so don't shoot me if I do not describe this properly.? As I understand it, that script then starts up the sBitx program in a new shell.? Anything that the sBitx program writes out to the console (stdio) is written to this new shell.? ?What was happening was that a program (? i2cbb.c? ) was madly writing error messages to this shell.? But it only did that whenever a CW key was being pressed.? ?So whenever sending CW, this shell kept growing and growing until it eventually ate all of the memory.? The sBitx program did not 'crash', it just eventually became totally unresponsive.? In fact the entire Pi Zero became so sluggish that it took it 15 minutes to produce a directory listing.
?
This ic2bb.c program was writing out messages when (1) it tried to get control of the I2C bus, but could not because the I2C bus was already busy, and (2) whenever it got so backed up with the rush of incoming requests for the I2C bus that it aborted and reconnected.? This? ic2bb.c? program was not changed during the upgrade from version 3.021 to 3.052.? But in version 3.052 it is being called 'a whole lot more'.?
?
I have made an initial fix.? I have tested my initial fix by running my zBITX for the last 4 hours, while periodically sending some CW, and watching the memory usage.? ?What was my initial fix?? ?I commented out all of the messages that I2cbb.c was writing out to this shell, causing it to grow to an astronomical size.
?
So why now in version 3.052 and not in version 3.021?? The root cause was adding in the Interrupts (IRQs) for the manual CW Mode.? ?I see two things that caused the? i2Cbb.c functions to become overwhelmed :? The new IRQs are now being generated on 'Key Contact Closed' and 'Key Contact Open'.? Only Key Contact Closed is needed.? ?And the IRQ processing function is is not debouncing the Key Contact Closed (or Key Contact Opened).? ?What you may think is one Contact Closure generating one Interrupt, is really one Contact Closure generating tens to hundreds of Interrupts. Even though I have inhibited the messages that were causing the memory eating problem, this massive influx of unnecessary interrupts is still occurring and is still overwhelming the functions handling the I2C bus, which is causing unnecessary instability in the device.? ?
?
So,? I will be going back into the version 3.052 sbitx_gtk.c, and making these IRC related changes.? Once I have finished that and have tested it, I will post my new i2cbb.c program and my new sbitx_gtk.c program.
?
If you are inclined to do a quick fix for your i2cbb.c program yourself, just go into it and comment out every? printf()? that is in there.? Then do a? ./build,? power down and power back up.
?
72,
Jody - K3JZD? ? ??
?
?
??
