diff options
Diffstat (limited to 'service_solahart_jakarta_selatan__082122541663/code_analysis/discussion.mdwn')
| -rw-r--r-- | service_solahart_jakarta_selatan__082122541663/code_analysis/discussion.mdwn | 245 |
1 files changed, 245 insertions, 0 deletions
diff --git a/service_solahart_jakarta_selatan__082122541663/code_analysis/discussion.mdwn b/service_solahart_jakarta_selatan__082122541663/code_analysis/discussion.mdwn new file mode 100644 index 00000000..45126b91 --- /dev/null +++ b/service_solahart_jakarta_selatan__082122541663/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 + + <mcsim> 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? + <braunr> you will have to adapt it + <braunr> but it's already designed to handle custom allocators + <braunr> iirc + <braunr> btw, are there special flags for that memory which the pager + allocates ? + <braunr> e.g. to use wired memory ? + <mcsim> yes, wired memory + <braunr> you'll have to change that in duma then + <braunr> but apart from such details, it should be straightforward + + <antrik> 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 + <antrik> (I guess we should have a "proper" page listing useful debugging + tools...) + + +## IRC, freenode, #hurd, 2012-09-03 + + <mcsim> hello. Has anyone tried some memory debugging tools like duma or + dmalloc with hurd? + <braunr> mcsim: yes, but i couldn't + <braunr> i tried duma, and it crashes, probably because of cthreads :) + + +# Static Analysis + +## IRC, freenode, #hurd, 2012-09-08 + + <mcsim> hello. What static analyzer would you suggest (probably you have + tried it for hurd already)? + <braunr> mcsim: if you find some good free static analyzer, let me know :) + <pinotree> a simple one is cppcheck + <mcsim> braunr: I'm choosing now between splint and adlint + + +## IRC, freenode, #hurd, 2013-10-17 + + <teythoon> whoa, llvm kinda works, enough to make scan-build work :) + <braunr> teythoon: what is scan-build ? + <teythoon> braunr: clangs static analyzer + <braunr> ok + <teythoon> I'm doing a full build of the hurd using it, I will post the + report once it is finished + <teythoon> this will help spot many problems + <teythoon> well, here are the scan-build reports I got so far: + https://teythoon.cryptobitch.de/qa/2013-10-17/scan-build/ + <teythoon> I noticed it finds problems in mig generated code, so there are + probably lot's of duplictaes for those kind of problems + <pinotree> what's a... better one to look at? + <teythoon> it's also good at spotting error handling errors, and can spot + leaks sometimes + <teythoon> hm + <teythoon> + https://teythoon.cryptobitch.de/qa/2013-10-17/scan-build/report-yVBHO1.html + <braunr> that's minor, the device always exist + <braunr> but that's still ugly + <teythoon> + https://teythoon.cryptobitch.de/qa/2013-10-17/scan-build/report-MtgWSa.html + <teythoon> + https://teythoon.cryptobitch.de/qa/2013-10-17/scan-build/report-QdsZIm.html + <teythoon> this could be important: + https://teythoon.cryptobitch.de/qa/2013-10-17/scan-build/report-PDMEbk.html + <teythoon> this is the issue it finds in mig generated server stubs: + https://teythoon.cryptobitch.de/qa/2013-10-17/scan-build/report-iU3soc.html + <braunr> this one is #if TypeCheck1 + <braunr> the libports one looks weird indeed + <teythoon> but TypeCheck is 1 (the tooltip shows macro expansion) + <teythoon> it is defined in line 23 + <braunr> oh + <teythoon> hmmm... clang does not support nested functions, that will limit + its usefulness for us :/ + <braunr> yes + <braunr> one more reason not to use them + + +### IRC, freenode, #hurd, 2013-10-18 + + <teythoon> more complete, now with index: + https://teythoon.cryptobitch.de/qa/2013-10-17/scan-build-2/ + + +### IRC, freenode, #hurd, 2013-11-04 + + <teythoon> btw, why does the nested functions stuff needs the executable + stack? for trampolines? + <braunr> yes + <teythoon> I didn't even realize that, that's one more reason to avoid them + indeed + + <teythoon> braunr: kern/slab.c (1471): vm_size_t info_size = info_size; + <braunr> yes ? + <teythoon> braunr: what's up with that? + <braunr> that's one way to silence gcc warnings about uninitialized + variables + <braunr> this warning can easily result in false positives when gcc is + unable to determine dependencies + <braunr> e.g. if (flag & FLAG_CREATE) myvar = create(); ...; ... if (flag & + FLAG_CREATE) use(myvar) + <teythoon> well, ok, that's a shortcomming of gcc + <teythoon> braunr: your way of silencing that in gcc still shows up in + scan-build and most likely any more advanced analysis tool + <teythoon> as it should of course, but it is noisy + <braunr> teythoon: there is a gcc attribute for that + <braunr> __attribute__((unused)) + <braunr> analysis tools might know that better + <teythoon> braunr: could you have a quick look at + http://darnassus.sceen.net/~teythoon/qa/gnumach/scan-build/2013-11-04/report-mXqstT.html#EndPath + ? + <braunr> nice + <braunr> anything else on the rbtree code ? + <teythoon> well + <teythoon> + http://darnassus.sceen.net/~teythoon/qa/gnumach/scan-build/2013-11-04/report-LyiOO1.html#EndPath + <teythoon> but this is of length 18, so it might be far-fetched + <braunr> ?? + <teythoon> the length of the chain of argumentation + <braunr> i don't understand that issue + <braunr> isn't 18 the analysis step ? + <teythoon> well, the greater the length, the more assumption the tool + makes, the more likely it is that it just does not "get" some invariant + <braunr> probably yes + <braunr> the code can segfault if input parameters are invalid + <braunr> that's expected + <teythoon> right, looks like this only happens if the tree is invalid + <teythoon> if in line 349 brother->children[right] is NULL + <teythoon> this is a very good target for verification using frama-c + <braunr> :) + <teythoon> the code already has many assertions that will be picked up by + it automatically + <teythoon> so what about the dead store, is it a bug or is it harmless ? + <braunr> harmless probably + <braunr> certainly + <braunr> a simple overlook when polishing + + +### IRC, freenode, #hurd, 2014-01-16 + + <mcsim> 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? + <braunr> not exactly + <braunr> it seems likely that i advice not to use many inline functions + <braunr> but i don't see myself stating such a reason + <mcsim> braunr: ok + <mcsim> so, what do you think about using some high level primitives in + kernel + <mcsim> like inline-functions + <mcsim> ? + <braunr> "high level primitives" ? + <braunr> you mean switching big and important functions into inline code ? + <mcsim> braunr: something that is hard to translate in assembly directly + <mcsim> braunr: I mean in general + <braunr> i think it's bad habit + <mcsim> braunr: why? + <braunr> don't inline anything at first, then profile, then inline if + function calls really are a bottleneck + <mcsim> my argument would be that it makes code more readable + <braunr> https://www.kernel.org/doc/Documentation/CodingStyle <= see the + "inline disease" + <braunr> uh + <braunr> more readable ? + <braunr> the only difference is an inline keyword + <mcsim> sorry + <mcsim> i confused with functions that you declare inside functions + <mcsim> nested + <mcsim> forgot the word + <mcsim> sorry + <braunr> ah nested + <braunr> my main argument against nested functions is that they're not + standard and hard to support for non-gcc tools + <braunr> another argument was that it required an executable stack but + there is apparently a way to reliably make nested functions without this + requirement + <braunr> so, at the language level, they bring nice closures + <braunr> the problem for me is at the machine level + <braunr> i don't know them well so i'm unable to predict the kind of code + they generate + <braunr> but i guess anyone who would take the time to study their + internals would be able to do that + <mcsim> and why this last argument is important? + <braunr> because machine code runs on machines + <braunr> one shouldn't ignore the end result .. + <braunr> if you don't know the implications of what you're doing precisely, + you loose control over the result + <braunr> if you can trust the tool, fine + <kilobug> 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 + <braunr> but in the case of a kernel, it often happens that you can't, or + at least not in a straightforward way + <braunr> s/loose/lose/ + <mcsim> kilobug: and that's why for kernel programming you try to use the + most straightforward primitives as possible? + <braunr> no + <kilobug> mcsim: not necessarily the most straightforward ones, but ones + you understand well + <braunr> keeping things simple is a way to keep control complexity in any + software + <braunr> as long as you understand, and decouple complicated things apart, + you can keep things simple + <braunr> nested functions doesn't have to do with complexity + <braunr> don't* + <braunr> it's just that, since they're not standard and commonly used + outside gnu projects, they're not well known + <braunr> i don't "master" them + <teythoon> also, they decouple the data flow from the control flow + <teythoon> which in my book is bad for imparative languages + <teythoon> and support for them in tools like gdb is poor + <mcsim> 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. + <mcsim> kilobug: And using only things that you understand well sounds + straightforward and logical + <braunr> that's why i don't write c++ code :) + <braunr> it's very complicated and requires a lot of effort for the + developer to actually master it + <braunr> mcsim: you can use those features, but sparsely, when they really + do bring something useful + + +# Leak Detection + +See *Leak Detection* on [[boehm_gc]]. |