1

I have been writing some pigpio apps and all of a sudden, they all start to fail. The error I get is:

initMboxBlock: init mbox zaps failed

The error is thrown from calls to

gpioInitialise()

My next step is to see if rebooting helps but I am hoping that there might be an explanation and a way to prevent this in future (assuming the reboot doesn't help).

Later ... a reboot cured the problem, but I'm still curious as to what may have happened.

Kolban
  • 1,784
  • 2
  • 16
  • 28

2 Answers2

2

If the code is running as a daemon, then I have seen this error appear in my syslog due to an improper shutdown - that is, without calling pigpio.terminate() on receiving shutdown signals, or not providing a handler for the signals at all. Here is the code -although javascript- that fixed it for me.

var pigpio = require('pigpio');
var Gpio = require('pigpio').Gpio,
    gpio;

//....

process.on('SIGHUP', shutdown);
process.on('SIGINT', shutdown);
process.on('SIGCONT', shutdown);
process.on('SIGTERM', shutdown);

function shutdown() {
  pigpio.terminate();
  clearInterval(timerVar);
  console.log('raspi2-brownout-watcher must exit, performed cleanup.');
  process.exit(0);
}
saraf
  • 571
  • 1
  • 4
  • 11
1

I'll have to check the code but off the top of my head the most likely is that the GPU (which allocates mbox DMA memory) has no spare memory.

By default 8MB is needed out of that assigned to the GPU.

If that's the case you'd need to use gpioCfgMemAlloc to specify the alternate style of DMA memory allocation (or allocate more memory to the GPU).

Does that sound feasible considering what you were doing at the time?

joan
  • 71,024
  • 5
  • 73
  • 106
  • Hi Joan, unfortunately I don't know either of the phrases "mbox" or "DMA memory" so I'm going to have to study on what those mean. What I can say is that it is extremely likely I was having memory leaks. In my coding, I kept getting SIGSEGVs from my code (my logic not pigpio) which may mean that pigpio was not getting an opportunity to "clean up" before the process terminated. If a Pigpio app terminates abnormally, is there a possibility for memory leakage? – Kolban Apr 27 '15 at 12:17
  • The pigpio library has a handler for every signal apart from the KILL and STOP signals which can't be trapped or ignored. With a few exceptions (USR1, USR2, PIPE, CHLD, WINCH) all signals are considered fatal and will lead to a safe termination. Were you trapping the SIGSEGVs? If pigpio was seeing them it should have terminated. – joan Apr 27 '15 at 13:33
  • My strange answer will be "I don't know". In my environment, I am making JNI calls from a Java JVM to Pigpio. So the Linux process is a Java JVM and the C code is dynamically loaded by JNI. To add even more potential mystery, we now have callbacks that can come from Pigpio originated threads that call back into the JVM. The bottom line, is that it is all hanging together (so far) but during development, there is every opportunity for the Pigpio library to have had its legs pulled from under it. – Kolban Apr 27 '15 at 20:18
  • I've got the same problem. Rebooting fixes it, but I'd still like to know why that is. @joan, do you have any ideas? – user46960 May 23 '16 at 21:14
  • Not really, I would try allocating more memory to the GPU (see /boot/overlays/README). – joan May 23 '16 at 21:50