-
Notifications
You must be signed in to change notification settings - Fork 204
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
If a message is subscribed, then unsubscribed, additional unsubscribes do not raise error events #862
Comments
This is likely a side-effect of a fix I implemented in #101 |
Yeah, actually looks to me like this will seg fault (tries to access NULL pointer). Note I'd like to add this as a test scenario to the new functional test framework (part of subscribe/unsubscribe API testing). |
I'm re-designing; can you point at the line you expect a seg fault? |
I don't think 1078 is true now, so 1083 will == NULL, and any of the following references to it would fault. Didn't test, but that's what it looks like to me upon inspection. cFE/fsw/cfe-core/src/sb/cfe_sb_api.c Lines 1078 to 1083 in 08f6eab
|
…now work as expected
Ah, yes...I am guessing RoutePtr will always be != NULL, but ListHeadPtr could be NULL and yes line 1087 would segfault. My redesign avoids this. |
fix #862 - unsub of a message ID that is already unsubbed
Describe the bug
If a message is subscribed, then unsubscribed, additional unsubscribes do not raise error events
To Reproduce
Have SB subscribe to a message
Have SB unsubscribe to that message
Have SB unsubscribe again to that message
Expected behavior
Event message should be raised
Code snips
cFE/fsw/cfe-core/src/sb/cfe_sb_api.c
Lines 1059 to 1112 in 08f6eab
If a message was previously subscribed to, and all pipes subscribing to it were subsequently unsubscribed, and an additional unsubscribe is issued, a valid routing index would still exist in the msgmap table, and thus an error event would not be raised.
System observed on:
N/A, discovered via code inspection
Additional context
N/A
Reporter Info
John N Pham, Northrop Grumman
The text was updated successfully, but these errors were encountered: