From 49a086299e047b18280457b654790ef4a2e5abfa Mon Sep 17 00:00:00 2001 From: Samuel Thibault Date: Wed, 18 Feb 2015 00:58:35 +0100 Subject: Revert "rename open_issues.mdwn to service_solahart_jakarta_selatan__082122541663.mdwn" This reverts commit 95878586ec7611791f4001a4ee17abf943fae3c1. --- open_issues/code_analysis/discussion.mdwn | 245 ++++++++++++++++++++++++++++++ 1 file changed, 245 insertions(+) create mode 100644 open_issues/code_analysis/discussion.mdwn (limited to 'open_issues/code_analysis') diff --git a/open_issues/code_analysis/discussion.mdwn b/open_issues/code_analysis/discussion.mdwn new file mode 100644 index 00000000..45126b91 --- /dev/null +++ b/open_issues/code_analysis/discussion.mdwn @@ -0,0 +1,245 @@ +[[!meta copyright="Copyright © 2011, 2012, 2013, 2014 Free Software Foundation, +Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_documentation]] + +[[!toc]] + + +# IRC, freenode, #hurd, 2011-12-04 + + defpager uses it's own dynamic memory allocator, which uses + vm_allocate/vm_deallocate as backing store? Am I able to use duma in such + case? + you will have to adapt it + but it's already designed to handle custom allocators + iirc + btw, are there special flags for that memory which the pager + allocates ? + e.g. to use wired memory ? + yes, wired memory + you'll have to change that in duma then + but apart from such details, it should be straightforward + + braunr: I have no idea about duma; but if you think it's a useful + tool, please add it to open_issues/code_analysis.mdwn + (I guess we should have a "proper" page listing useful debugging + tools...) + + +## IRC, freenode, #hurd, 2012-09-03 + + hello. Has anyone tried some memory debugging tools like duma or + dmalloc with hurd? + mcsim: yes, but i couldn't + i tried duma, and it crashes, probably because of cthreads :) + + +# Static Analysis + +## IRC, freenode, #hurd, 2012-09-08 + + hello. What static analyzer would you suggest (probably you have + tried it for hurd already)? + mcsim: if you find some good free static analyzer, let me know :) + a simple one is cppcheck + braunr: I'm choosing now between splint and adlint + + +## IRC, freenode, #hurd, 2013-10-17 + + whoa, llvm kinda works, enough to make scan-build work :) + teythoon: what is scan-build ? + braunr: clangs static analyzer + ok + I'm doing a full build of the hurd using it, I will post the + report once it is finished + this will help spot many problems + well, here are the scan-build reports I got so far: + https://teythoon.cryptobitch.de/qa/2013-10-17/scan-build/ + I noticed it finds problems in mig generated code, so there are + probably lot's of duplictaes for those kind of problems + what's a... better one to look at? + it's also good at spotting error handling errors, and can spot + leaks sometimes + hm + + https://teythoon.cryptobitch.de/qa/2013-10-17/scan-build/report-yVBHO1.html + that's minor, the device always exist + but that's still ugly + + https://teythoon.cryptobitch.de/qa/2013-10-17/scan-build/report-MtgWSa.html + + https://teythoon.cryptobitch.de/qa/2013-10-17/scan-build/report-QdsZIm.html + this could be important: + https://teythoon.cryptobitch.de/qa/2013-10-17/scan-build/report-PDMEbk.html + this is the issue it finds in mig generated server stubs: + https://teythoon.cryptobitch.de/qa/2013-10-17/scan-build/report-iU3soc.html + this one is #if TypeCheck1 + the libports one looks weird indeed + but TypeCheck is 1 (the tooltip shows macro expansion) + it is defined in line 23 + oh + hmmm... clang does not support nested functions, that will limit + its usefulness for us :/ + yes + one more reason not to use them + + +### IRC, freenode, #hurd, 2013-10-18 + + more complete, now with index: + https://teythoon.cryptobitch.de/qa/2013-10-17/scan-build-2/ + + +### IRC, freenode, #hurd, 2013-11-04 + + btw, why does the nested functions stuff needs the executable + stack? for trampolines? + yes + I didn't even realize that, that's one more reason to avoid them + indeed + + braunr: kern/slab.c (1471): vm_size_t info_size = info_size; + yes ? + braunr: what's up with that? + that's one way to silence gcc warnings about uninitialized + variables + this warning can easily result in false positives when gcc is + unable to determine dependencies + e.g. if (flag & FLAG_CREATE) myvar = create(); ...; ... if (flag & + FLAG_CREATE) use(myvar) + well, ok, that's a shortcomming of gcc + braunr: your way of silencing that in gcc still shows up in + scan-build and most likely any more advanced analysis tool + as it should of course, but it is noisy + teythoon: there is a gcc attribute for that + __attribute__((unused)) + analysis tools might know that better + braunr: could you have a quick look at + http://darnassus.sceen.net/~teythoon/qa/gnumach/scan-build/2013-11-04/report-mXqstT.html#EndPath + ? + nice + anything else on the rbtree code ? + well + + http://darnassus.sceen.net/~teythoon/qa/gnumach/scan-build/2013-11-04/report-LyiOO1.html#EndPath + but this is of length 18, so it might be far-fetched + ?? + the length of the chain of argumentation + i don't understand that issue + isn't 18 the analysis step ? + well, the greater the length, the more assumption the tool + makes, the more likely it is that it just does not "get" some invariant + probably yes + the code can segfault if input parameters are invalid + that's expected + right, looks like this only happens if the tree is invalid + if in line 349 brother->children[right] is NULL + this is a very good target for verification using frama-c + :) + the code already has many assertions that will be picked up by + it automatically + so what about the dead store, is it a bug or is it harmless ? + harmless probably + certainly + a simple overlook when polishing + + +### IRC, freenode, #hurd, 2014-01-16 + + braunr: hi. Once, when I wrote a lot if inline gcc functions in + kernel you said me not to use them. And one of the arguments was that you + want to know which binary will be produced. Do you remember that? + not exactly + it seems likely that i advice not to use many inline functions + but i don't see myself stating such a reason + braunr: ok + so, what do you think about using some high level primitives in + kernel + like inline-functions + ? + "high level primitives" ? + you mean switching big and important functions into inline code ? + braunr: something that is hard to translate in assembly directly + braunr: I mean in general + i think it's bad habit + braunr: why? + don't inline anything at first, then profile, then inline if + function calls really are a bottleneck + my argument would be that it makes code more readable + https://www.kernel.org/doc/Documentation/CodingStyle <= see the + "inline disease" + uh + more readable ? + the only difference is an inline keyword + sorry + i confused with functions that you declare inside functions + nested + forgot the word + sorry + ah nested + my main argument against nested functions is that they're not + standard and hard to support for non-gcc tools + another argument was that it required an executable stack but + there is apparently a way to reliably make nested functions without this + requirement + so, at the language level, they bring nice closures + the problem for me is at the machine level + i don't know them well so i'm unable to predict the kind of code + they generate + but i guess anyone who would take the time to study their + internals would be able to do that + and why this last argument is important? + because machine code runs on machines + one shouldn't ignore the end result .. + if you don't know the implications of what you're doing precisely, + you loose control over the result + if you can trust the tool, fine + mcsim: in general, when you use something you don't really + understand how it works internally, you've a much higher risk of making + bugs or inefficient code because you just didn't realize it couldn't work + or would be inefficient + but in the case of a kernel, it often happens that you can't, or + at least not in a straightforward way + s/loose/lose/ + kilobug: and that's why for kernel programming you try to use the + most straightforward primitives as possible? + no + mcsim: not necessarily the most straightforward ones, but ones + you understand well + keeping things simple is a way to keep control complexity in any + software + as long as you understand, and decouple complicated things apart, + you can keep things simple + nested functions doesn't have to do with complexity + don't* + it's just that, since they're not standard and commonly used + outside gnu projects, they're not well known + i don't "master" them + also, they decouple the data flow from the control flow + which in my book is bad for imparative languages + and support for them in tools like gdb is poor + braunr: I remembered nested functions because now I use C++ and I + question myself if I may use all these C++ facilities, like lambdas, + complicated templates and other stuff. + kilobug: And using only things that you understand well sounds + straightforward and logical + that's why i don't write c++ code :) + it's very complicated and requires a lot of effort for the + developer to actually master it + mcsim: you can use those features, but sparsely, when they really + do bring something useful + + +# Leak Detection + +See *Leak Detection* on [[boehm_gc]]. -- cgit v1.2.3