summaryrefslogtreecommitdiff
path: root/open_issues/code_analysis/discussion.mdwn
blob: 4cb03293b032c40420e4c08ff0ac3aa105d97e7a (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
[[!meta copyright="Copyright © 2011, 2012, 2013 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/


# Leak Detection

See *Leak Detection* on [[boehm_gc]].