summaryrefslogtreecommitdiffstats
path: root/tests/logging
Commit message (Collapse)AuthorAgeFilesLines
* logging: Introduce mutex API to manage log_target in multi-thread envsPau Espin Pedrol2019-10-091-0/+1
| | | | | | | | | | | | | | | | | | | | log_enable_multithread() enables use of locks inside the implementation. Lock use is disabled by default, this way only multi-thread processes need to enable it and suffer related complexity/performance penalties. Locks are required around osmo_log_target_list and items inside it, since targets can be used, modified and deleted by different threads concurrently (for instance, user writing "logging disable" in VTY while another thread is willing to write into that target). Multithread apps and libraries aiming at being used in multithread apps should update their code to use the locks introduced here when containing code iterating over osmo_log_target_list explictly or implicitly by obtaining a log_target (eg. osmo_log_vty2tgt()). Related: OS#4088 Change-Id: Id7711893b34263baacac6caf4d489467053131bb
* add vty logp command to echo on all log targetsNeels Hofmeyr2019-08-131-0/+53
| | | | | | | | | | | | | | | | | | | | | | | | | | | When reading SUT logs resulting from TTCN3 runs, it can be hard to figure out which log section corresponds to which test code. Add a 'logp' command on VIEW and ENABLE nodes that simply echos an arbitrary message on log output, useful to set markers / explanations from the TTCN3 code, which then appear in all log outputs and can make it trivial to figure out which log section is interesting. logging_vty_test# logp lglobal notice This is the log message DLGLOBAL NOTICE This is the log message From TTCN3, could be used like this, e.g. in BSC_Tests.ttcn: private function f_logp(charstring log_msg) runs on MSC_ConnHdlr { // log on TTCN3 log output log(log_msg); // log in stderr log f_vty_transceive(BSCVTY, "logp lglobal notice " & log_msg); } ... f_logp("f_probe_for_handover(" & log_label & "): Ending the test: Handover Failure stops the procedure."); Change-Id: Ife5dc8999174c74e0d133729284fe526d6eaf8d9
* tests: logging: Remove undefined param passed to logging_vty_add_cmdsPau Espin Pedrol2019-08-051-1/+1
| | | | | | | | | | | Since March 15th 2017, libosmocore API logging_vty_add_cmds() had its parameter removed (c65c5b4ea075ef6cef11fff9442ae0b15c1d6af7). However, definition in C file doesn't contain "(void)", which means number of parameters is undefined and thus compiler doesn't complain. Let's remove parameters from all callers before enforcing "(void)" on it. Related: OS#4138 Change-Id: Iaea795521361a8e5b3b45eaeb35e6eda69163af3
* Enable remote SIM protocol log levelMax2019-02-141-1/+1
| | | | | | | It's defined in logging.h for quite some time but is not actually enabled alongside with other internal logging categories. Change-Id: I0e7a2add6293a072752900608c8ba34cc3850f31
* vty logging: fix crash when missing 'logging enable'Neels Hofmeyr2018-10-011-0/+3
| | | | | | | | | | | | | | | We must explicitly check the return value of osmo_log_vty2tgt(), or may run into a segfault. I wasn't aware of this and introduced numerous such cases in I36f17c131cc70ce5a1aef62fd9693097de230cd4. Reproduce: on the VTY, do not issue 'logging enable', invoke 'logging level force-all LEVEL' first. Show in logging_vty_test.vty that this situation is now again amended by telling the user that logging was not enabled. Related: OS#3611 Change-Id: Id11702d1801d6654ca5e5a51b597a0d802e2e8dd
* logging_vty: Ensure writing well-formed config filesHarald Welte2018-09-251-6/+6
| | | | | | | We want to have well-formed config files that print exactly one space per VTY/config node level, and not two. Change-Id: Ia75c7067284ea225cffe13ca71bad05a7747ae66
* logging vty: add 'logging level set-all <level>'Neels Hofmeyr2018-09-161-0/+161
| | | | | | | | | Add new command to once-off set each and every category to the given log level, as discussed at length on the openbsc@ mailing list. Show that it works in logging_vty_test.vty. Change-Id: I4c3e4f786476cb813fdc0a7c64f30ee04758309d
* logging vty: deprecate 'all', introduce 'force-all'Neels Hofmeyr2018-09-131-14/+134
| | | | | | | | | | | | | | | Add 'logging level force-all <level>' and 'no logging level force-all' as new names for 'logging level all <level>' and 'logging level all everything'. Resurrect the functionality of 'logging level all everything' -- even if it is still deprecated because the name is confusing, it is now just an alias for 'no logging level force-all'. Show in logging_vty_test.vty that we can now again lift the global logging clamp, both with the new commands as well as with the deprecated ones. Also show that 'force-all' is written back properly, if set. Change-Id: I36f17c131cc70ce5a1aef62fd9693097de230cd4
* logging vty: deprecate the 'everything' keywordNeels Hofmeyr2018-09-131-17/+13
| | | | | | | | | | | | | | | | The 'logging level all everything' has not had an effect for some time now. The plan is to bring back its old functionality, but to keep it deprecated and rather define a less confusing name. * Deprecate 'everything'. * Do not write 'everything' during 'write file' or 'show running-config', which we curiously still do until now. BTW, the reason why we need to compose a complete list of categories for the deprecated 'everything' command is explained in detail in the commit log for I3b083f27e3d751ccec258880ae7676e9af959a63 Change-Id: Ib75fedb0572570a61bb34ee729a2af86cf5f16da
* logging vty: add VTY transcript testNeels Hofmeyr2018-09-122-0/+486
| | | | | | | | | | | | | | | | | | | | | | | | I am setting out to refactor various details about logging. To show the effect, I am first adding this new test to illustrate the exact effects on the various osmo programs. Add logging_vty_test.c as a standalone program that simply defines a few logging categories and opens a telnet vty to play with. Add logging_vty_test.vty, as an osmo_verify_transcript_vty.py test script. Add --enable-external-tests to configure.ac, to enable running logging_vty_test.vty during 'make check'. Also allow running 'make vty-test' without the need to first configure with --enable-external-tests (a flexibility I've missed many times over in the other osmo source trees). Add a Makefile.am stub for external CTRL tests, basically a copy-paste from osmo-msc.git. I doubt that libosmocore will get python driven CTRL interface testing any time soon, but if so we will know to not run it concurrently. Change-Id: I948e832a33131f8eab98651d6010ceb0ccbc9a9c
* license: Fix the license to GPLHolger Hans Peter Freyther2017-12-091-4/+5
| | | | | | | | This was always intended to be GPL and not AGPL. "kat" did the development as part of an internship paid by me and we agreed to shared copyright. Change-Id: Ied2041ba20c5737bd967dfaa3017edf72a95b31c
* fix logging: log_set_category_filter() for internal DL* logging catsNeels Hofmeyr2016-12-121-0/+1
| | | | | | | | | | | | | | | | | | In log_set_category_filter(), passing a negative index lead to memory corruption. Particularly dangerous since the internal logging categories have negative values. Fix: apply map_subsys() to interpret negative values as internal logging categories. As a side effect, out-of-bounds logging categories will be mapped to DLGLOBAL instead of being dropped. Fix the expectations in logging_test to match the fixed bug. While at it also guard against a NULL logging target. Change-Id: Ib0725b22bc39498c6b3970a61eb3339cf56d19f1
* show bug in logging: log_set_category_filter on DL* categoriesNeels Hofmeyr2016-12-121-0/+6
| | | | | | | | | | | | | | Add a check to logging_test.c to show a bug: passing an internal DL* category constant to log_set_category_filter() results in a negative array index and undefined behavior. A sanitize build should catch this. The bug is confirmed by the fact that logging_test.err stays the same (hopefully) although a logging output should appear from this patch. The test could as well segfault or anything else, it's a bit of a gamble. This bug will be fixed along with the expectation in a subsequent patch. Change-Id: Ie2da77c642a84cafc0f528985930697ec167183b
* fix logging: out-of-bounds check should end with user categoriesNeels Hofmeyr2016-12-121-0/+1
| | | | | | | | | | | | | To check category bounds, rather use num_cat_user, to redirect all semantically unknown categories to DLGLOBAL. Adjust logging_test expectations accordingly: "(d)" is now also shown. Note: subsys is and needs to be signed, while num_cat* are unsigned. Thus for a negative subsys, 'subsys >= num_cat_user' practically always yields true. Pay close attention to signedness and check upper bound only for positive values. Change-Id: I4a952b759f30d90fbfb81fedcfc56a8092ea18c1
* show bug in logging: out-of-bounds check should end with user categoriesNeels Hofmeyr2016-12-122-0/+5
| | | | | | | | | | | | | | | | | | | In the background osmo_log_info array, the user's logging categories are enhanced by the library internal ones. So far logging category range checking only checked for the larger array bounds, although passing a logging category >= num_cat_user is already semantically unknown and should redirect to DLGLOBAL. Add a check to logging_test.c to show that this isn't happening. Instead of DLGLOBAL, a logging category that happens to be at that index is queried. The bug is confirmed by logging_test.err only showing "(e)" and not "(d)": "(e)" is shown because the first category after the user ones happens to be DLGLOBAL. "(d)" is omitted since it hits a category that's not on debug level. This bug will be fixed along with the expectation in a subsequent patch. Change-Id: I397278714018ee9a0ae5101515f31ddddf79c2ec
* fix logging: also catch first out-of-bounds logging catNeels Hofmeyr2016-12-121-0/+1
| | | | | | | | | | In map_subsys(), fix the '>' condition to '>=' for array bounds checking. Also make the bounds checking more strict: after both invocations of subsys_lib2index(), re-check validity of the array index. If the final index is still wrong, which should never happen, exit by assertion. Change-Id: I7ca1a1d47724e40350f1c4dfebe90bad01c965f9
* show bug in logging: erratic redirection to DLGLOBAL for first invalid categoryNeels Hofmeyr2016-12-121-0/+1
| | | | | | | | | | | | | | | | Add a check to logging_test.c to show a bug: when a logging category value that is the first out-of-bounds value is passed to the logging system, the internal map_subsys() fails to redirect to DLGLOBAL due to a flawed conditional. This results in a too large array index and undefined behavior. A sanitize build should catch this. The bug is confirmed by the fact that logging_test.err stays the same (hopefully) although a logging output should appear from this patch. The test could as well segfault or anything else, it's a bit of a gamble. This bug will be fixed along with the expectation in a subsequent patch. Change-Id: I12bf38b6c1f85e2d7bf5a15f942dfe0beed41eba
* fix logging: redirection to DLGLOBAL for invalid categoriesNeels Hofmeyr2016-12-121-0/+2
| | | | | | | | | | | For out-of-bounds logging categories, redirect to the proper DLGLOBAL array index instead of returning -1. Adjust test expectation which shows that the bugs tested for are fixed. Note: there are separate bounds checking problems, left for another patch. Change-Id: I6ea9a59e005a22e0305454291714fdb9531c346b
* show bug in logging: erratic redirection to DLGLOBAL for invalid categoriesNeels Hofmeyr2016-12-121-0/+8
| | | | | | | | | | | | | | | | | | | | Add a check to logging_test.c to show a bug: when a logging category value that is out-of-bounds is passed to the logging system, the internal map_subsys() function should remap that to DLGLOBAL. But in fact DLGLOBAL is -1 and the function fails to map this to a proper positive array index, directly returning -1 instead. This results in a negative array index and undefined behavior. A sanitize build should catch this. The bug is confirmed by the fact that logging_test.err stays the same (hopefully) although a logging output should appear from this patch. The test could as well segfault or anything else, it's a bit of a gamble. This bug will be fixed along with the expectation in a subsequent patch. Note: osmo_log_info->num_cat + 0 is also out-of-bounds, but there is a separate bug there, so leaving this for another patch. Change-Id: I161b6550fa204a872bad1abefee1a6155393fafd
* logging test: cosmetic: print target and don't print colorNeels Hofmeyr2016-12-122-4/+5
| | | | | | | Prepares for upcoming modifications of the logging test to show and fix bugs in the logging system. Change-Id: I9461b987adf85d87469a6af55de5f1aa478f6ebb
* logging: Move the filter check up as wellHolger Hans Peter Freyther2016-02-292-7/+15
| | | | | | There doesn't seem to be a reason not to check the filter. Update and extend the test. Currently the filter function will be called once for the log check and once for the output of it.
* log/test: Extend test case for log_check_levelJacob Erlbeck2016-02-292-1/+11
| | | | | | | | This commit adds OSMO_ASSERTs for mandatory conditions related to log_check_level, and fprintfs for optional conditions, since it is always safe for log_check_level to return != 0. Sponsored-by: On-Waves ehf
* logging: Copy the filter_fn and fix the IMSI filter in OpenBSCHolger Hans Peter Freyther2013-12-291-0/+17
| | | | | | | The filter_fn has not been copied into the new structure breaking the imsi and other filters in OpenBSC. Looking at the code we should also introduce a callback for the reset of the context so we could use subscr_get/subscr_put on the subscriber structure.
* logging: Modify the testcase to excercise Nico's fixHolger Hans Peter Freyther2012-09-271-1/+1
|
* logging: Move the logging test from OpenBSC into libosmocoreHolger Hans Peter Freyther2012-09-273-0/+79
Add a testcase for the logging facility. The test is coming from the OpenBSC code.