Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SEG FAULT when returning from function after read() #46

edoardoo opened this issue Dec 3, 2014 · 2 comments

SEG FAULT when returning from function after read() #46

edoardoo opened this issue Dec 3, 2014 · 2 comments


Copy link

@edoardoo edoardoo commented Dec 3, 2014

Hi, sorry to bother again. I'm stucked on this issue/bug, would like to know if it is a known bug or I am doing something wrong.

Hardware: Raspberry B ver1 and Arduino Nano 328, both with NRF24l01+, filtered DC with capacitors.

How to reproduce:
Alter the gettingstarted.cpp code:

  • edit the while(1) infinte loop to exit after a .read() occurs, perhaps after writing buffer got_time line 139 .
  • run the application from root (sudoer account seems to hide the error)

Expected result: the application exit with 0 status.

Actual result: the application exit with segmentation fault.

Additional Info:
in gdb I've found this error
c++ crash in fflush () from /lib/arm-linux-gnueabihf/

It looks like, maybe, that read() function is messing with the stack, although didn't have a way to test my sentence.
Please note: Gettingstarted application works perfectly fine, I believe it's because the only way to kill it is with ctrl+c.

Copy link

@TMRh20 TMRh20 commented Dec 3, 2014

Weird.. and the weirdness continues...

So, I somewhat narrowed this error down to the read_payload() function in the RF24 driver, and managed to work around the error, but I'm still not quite sure as to the cause.

In any case, if you declare unsigned long got_time; globally, before int main(int argc, char** argv){ there will be no more seg faults.

In comparing the code in RF24 between the read_payload() function and say read_register() functions, the only difference is the void* used in read_payload, so am assuming it has something to do with that, but not sure exactly what.

I also tried calling bcm2835_spi_end(); and bcm2835_close(); before exiting to no avail.

TMRh20 added a commit that referenced this issue Dec 15, 2014
- Per #46 the read_payload() function was over-reading data into the
user provided buffer
Copy link

@TMRh20 TMRh20 commented Dec 15, 2014

Thank you for submitting this issue, and doing it in such a detailed fashion. After a whole bunch of debugging, and now that I've spotted the issue, I'm surprised I didn't catch it sooner, but hindsight and all...
In any case, thanks for the perfectly detailed description of the problem, symptoms, and code/steps to reproduce it. For some reason, this one wasn't so easy to find, but that makes it a whole lot easier.

Please feel free to close the issue if you are able to confirm resolution.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants