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
  https://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>
  https://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.