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

Closed
edoardoo opened this Issue Dec 3, 2014 · 2 comments

Comments

Projects
None yet
2 participants
@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/libc.so.6

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.

@TMRh20

This comment has been minimized.

Show comment
Hide comment
@TMRh20

TMRh20 Dec 3, 2014

Member

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.

Member

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

Fix: RPi memory corruption
- Per #46 the read_payload() function was over-reading data into the
user provided buffer
@TMRh20

This comment has been minimized.

Show comment
Hide comment
@TMRh20

TMRh20 Dec 15, 2014

Member

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.

Member

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