From 95878586ec7611791f4001a4ee17abf943fae3c1 Mon Sep 17 00:00:00 2001 From: "https://me.yahoo.com/a/g3Ccalpj0NhN566pHbUl6i9QF0QEkrhlfPM-#b1c14" Date: Mon, 16 Feb 2015 20:08:03 +0100 Subject: rename open_issues.mdwn to service_solahart_jakarta_selatan__082122541663.mdwn --- open_issues/code_analysis/discussion.mdwn | 245 ------------------------------ 1 file changed, 245 deletions(-) delete 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 deleted file mode 100644 index 45126b91..00000000 --- a/open_issues/code_analysis/discussion.mdwn +++ /dev/null @@ -1,245 +0,0 @@ -[[!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