-
Notifications
You must be signed in to change notification settings - Fork 47
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 writing topic #260
Comments
After digging a lot further it appears that this issue is probably related to the use of sequences in the OARIS sensor_track_type struct. When the sequences are empty they appear not to deserialise correctly (or maybe serialise) and the bytes are offset, leading to incorrect behaviour. |
Interesting ... I went down another path and found something that I thought completely explained it. My analysis is that the crash is caused because the Python serializer can produce garbage while the (small amount of) C support code in the Python binding assumes its input is well-formedness. The Python code gets a value from the application and serializes it to CDR, and then the C code extracts the key value from the CDR. There's no user/network input involved between the output of the one and the input of the other, so assuming the input is well-formed is a seemingly reasonable assumption. However ... here we have an incorrect application sample (assuming I transcribed the output you quoted correctly), because
should've been:
The Python serializer gets to the It just so happens that the (little-endian) serialized representation of Thus, the two go out of sync. At some point the input sequence makes no sense anymore: it reads a byte encoding boolean but gets the number 144. The C verifier stops right there, but the key extraction procedure doesn't because it assumes well-formed input. We probably should run the verifier just in case. I don't know Python well enough to even know whether this type confusion problem can be fixed in Python at all. Perhaps you can give #261 a try? I have done a lot of testing, but it does detect the malformed CDR for this particular sample and ends up raising a "bad parameter" exception, which I think is correct. |
Hah, you've been just slightly quicker at finding that than I have! Just identified the same thing after going text blind staring at the output. I'll have a look at 261 and see if it rejects the bad input. |
@eboasson #261 does rectify the issue by giving an alert related to a bad parameter. I think when I was looking yesterday after a day of bashing my head against why this was only working sometimes I completely missed the malformatted parameter. There must have been a few occasions where the data that was fed in lined up just enough to make things nearly work which was throwing me off entirely. |
Approximately 50% of the time when writing an OARIS Sample a Seg fault occurs on writing. The python script hangs for upwards of 60 seconds and then exits reporting a Segmentation Fault as follows:
I have also run the same program using gdb which returns the following
I initially thought that I might be generating the sample incorrectly, but I am somewhat confused by the sample occasionally writing. Any input gratefully received!
The program is really simple, just creating and then writing the above sample. The cyclonedds config file is completely default apart from specifying a NIC. This latest (downloaded 1 Jul 24) version of cyclonedds and cyclonedds-python with the IDL compiled against the same.
The text was updated successfully, but these errors were encountered: