hmm, debugging is a problem in opensc code. here are my ideas. I haven't figured out how to ltrace opensc, mostly when it used via opensc- pkcs11.so. so what can I do to find a bug? a) gdb and single step, taking notes till I find out how opensc works in some area and get a clue where the bug is. b) ask for a log file and see if I can figure out what is going wrong.
but a) doesn't help if other people have a problem, I would need to reproce the problem first, and thus very few people can debug a problem (those with the same OS, the same app, the same card...). b) also doesn't work great. some parts are far to noisy (card matching works well, but generates hundreds of lines of debug code). and asn.1 analysis might be too chatty too, unless of course the problem is wit the format of some card - missing or extra entries etc. also not every function has good debug code, e.g. the parameters aren't in the debug file, so I have little clue what is going on. having no debug code/files is not an option, I guess. so the best we can do is to go through functions, and make sure each and every core function prints debug info when entered (including the parameters), and prints the result when it is leaving. extra debug in the middle, if it is a complex function is welcome too. so what is useful of the code in src/libopensc/log.h? sc_error should and everything related to error fd needs to go - it caused debug log files without the error information, a very bad idea. (IIRC martin did that already?) every debug macro or function call should contain the debug level, and the macro/function should check it against ctx->debug. all log.h functions get the context already. SC_FUNC_CALLED should go away - functions have parameters, those help in debugging a lot. SC_FUNC_RETURN doesn't tell us what is returned (unless the function returns only the value). so if we change the code, can we find better macros / ways to debug problems? __FILE__ and __LINE__ are not very important to me, at least it is easy to find out where a function begins, even without that. but parameters or some detailed info what went wrong, that all could help. > Does it exists any rule for the assigning of the debug level for debug > messages ? lets put everything at 1, isolate whole function blocks that are too chatty, and put them on a different level. (asn.1=2, card matching=3?). we could also go for a flag based system, if that is preferable. also (thought I guess it is already gone): suppressing errors isn't fine with me. without debugging active, opensc shouldn't print anything. that is what return codes are for, maybe the app can handle it. not printing stuff when debugging is on might leave out important parts too. what do you think? Regards, Andreas _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
