<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...)
<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 :)
<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
<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
<teythoon> more complete, now with index: https://teythoon.cryptobitch.de/qa/2013-10-17/scan-build-2/
<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
<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
See Leak Detection on boehm gc.