36 | | |
| 36 | === It's an assertion, and not a crash, dammit! :) === #assert |
| 37 | |
| 38 | Very often we receive a report that PJSIP crashes, while actually it's ''just'' an assertion. This makes a big difference for us in terms of troubleshooting, since a crash means fatal bug, while assertion just serves as warning thus is not fatal. |
| 39 | |
| 40 | In PJSIP, we use assertion as means to warn the developer that something unexpected has happened. This may due to some wrong assumption during development, some invalid value being passed, or some other mistakes done by the developer. The conventions are: |
| 41 | * assertion should only be raised for unexpected errors generated locally. For errors coming from external sources (such as a malformed SIP message received from remote), it must not raise assertion and rather the usual error handling must be performed. |
| 42 | * assertion must not replace a proper error handling, thus when assertion is disabled, the program should fallback to using error handling as usual. |
| 43 | |
| 44 | We use [http://www.pjsip.org/pjlib/docs/html/group__pj__assert.htm#gc98bea768b573f53432076a387864fb3 PJ_ASSERT_RETURN()] macro a lot. The idea of this macro is to raise an assertion during development so that any problems can be fixed early, and on the production release where assertion is disabled, the macro will revert to error handling. |
| 45 | |
| 46 | So yes, '''you should disable assertion on the release version''' of the software. |
| 47 | |
| 48 | In conclusion, please distinguish between assertion and crash when reporting a problem so that we can give the report the appropriate attention. |