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
|
[[!meta copyright="Copyright © 2012 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_hurd]]
libports/port-ref.c:31: ports_port_ref: Assertion `pi->refcnt || pi->weakrefcnt' failed
This is seen every now and then.
# [[gnumach_page_cache_policy]]
With that patch in place, the assertion failure is seen more often.
## IRC, freenode, #hurd, 2012-07-14
<youpi> braunr: I'm getting ext2fs.static:
/usr/src/hurd-debian/./libports/port-ref.c:31: ports_port_ref: Assertion
`pi->refcnt || pi->weakrefcnt' failed.
<youpi> oddly enough, that happens on one of the buildds only
<braunr> :/
<braunr> i fear the patch can wake many of these issues
## IRC, freenode, #hurd, 2012-07-15
<youpi> braunr: same assertion failed on a second buildd
<braunr> can you paste it again please ?
<youpi> ext2fs.static: /usr/src/hurd-debian/./libports/port-ref.c:31:
ports_port_ref: Assertion `pi->refcnt || pi->weakrefcnt' failed.
<braunr> or better, answer the ml thread for future reference
<braunr> thanks
<youpi> braunr: I can't keep your patch on the buildds, it makes them too
unreliable
<braunr> youpi: ok
<braunr> i never got this error though, that's weird
<braunr> youpi: was the failure during the same build ?
<youpi> no, it was during package installation, and not the same
<youpi> braunr: note that I've already seen such errors, it's not new, but
it was way rarer
<youpi> like every month only
<braunr> ah ok
<braunr> yes it's less surprising then
<braunr> a tricky reference counting / locking mistake somewhere in the
hurd :) ...
<braunr> ah ! just got it !
<bddebian> braunr: Got the error or found the problem? :)
<braunr> the former unfortunately :/
## IRC, freenode, #hurd, 2012-07-19
<braunr> hm, i think those ext2fs port refs errors may also be due to stack
overflows
<pinotree> --verbose
<braunr> hm ?
<braunr> http://lists.gnu.org/archive/html/bug-hurd/2012-07/msg00051.html
<pinotree> i mean, why do you think they could be due to that?
<braunr> the error is that both strong and weak refs in a port are 0 when
adding a reference
<braunr> weak refs are almost never used so let's forget about them
<braunr> when a ref count drops to 0, the port is automatically deallocated
<braunr> so what other than memory corruption setting this counter to 0
could possibly do that ? :)
<pinotree> one could also guess an unbalanced ref/unref logic, somehow
<braunr> what do you mean ?
<pinotree> that for a bug, an early return, etc a port gets unref'ed often
than it is ref'ed
<braunr> highly unlikely, as they're protected by a lock
<braunr> pinotree: ah you mean, the object gets deallocated early because
of an deref overflow ?
<braunr> pinotree: could be, yes
<braunr> pinotree: i wonder if it could happen because of the periodic sync
duplicating the node table without holding references
<braunr> rah, libports uses a big lock in many places :(
<pinotree> braunr: yes, i meant that
<braunr> we could try using libduma some day
<braunr> i wonder if it could work out of the box
<pinotree> but that wouldn't help to find out whether a port gets deref'ed
too often, for instance
<pinotree> although it could be adapted to do so, i guess
<braunr> reproducing + a call trace or core would be best, but i'm not even
sure we can get that easily lol
[[automatic_backtraces_when_assertions_hit]].
|
