[[!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]].