From 2603401fa1f899a8ff60ec6a134d5bd511073a9d Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Tue, 7 Aug 2012 23:25:26 +0200 Subject: IRC. --- ...t2fs_libports_reference_counting_assertion.mdwn | 93 ++++++++++++++++++++++ 1 file changed, 93 insertions(+) create mode 100644 open_issues/ext2fs_libports_reference_counting_assertion.mdwn (limited to 'open_issues/ext2fs_libports_reference_counting_assertion.mdwn') diff --git a/open_issues/ext2fs_libports_reference_counting_assertion.mdwn b/open_issues/ext2fs_libports_reference_counting_assertion.mdwn new file mode 100644 index 00000000..ff1c4c38 --- /dev/null +++ b/open_issues/ext2fs_libports_reference_counting_assertion.mdwn @@ -0,0 +1,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 + + braunr: I'm getting ext2fs.static: + /usr/src/hurd-debian/./libports/port-ref.c:31: ports_port_ref: Assertion + `pi->refcnt || pi->weakrefcnt' failed. + oddly enough, that happens on one of the buildds only + :/ + i fear the patch can wake many of these issues + + +## IRC, freenode, #hurd, 2012-07-15 + + braunr: same assertion failed on a second buildd + can you paste it again please ? + ext2fs.static: /usr/src/hurd-debian/./libports/port-ref.c:31: + ports_port_ref: Assertion `pi->refcnt || pi->weakrefcnt' failed. + or better, answer the ml thread for future reference + thanks + braunr: I can't keep your patch on the buildds, it makes them too + unreliable + youpi: ok + i never got this error though, that's weird + youpi: was the failure during the same build ? + no, it was during package installation, and not the same + braunr: note that I've already seen such errors, it's not new, but + it was way rarer + like every month only + ah ok + yes it's less surprising then + a tricky reference counting / locking mistake somewhere in the + hurd :) ... + ah ! just got it ! + braunr: Got the error or found the problem? :) + the former unfortunately :/ + + +## IRC, freenode, #hurd, 2012-07-19 + + hm, i think those ext2fs port refs errors may also be due to stack + overflows + --verbose + hm ? + http://lists.gnu.org/archive/html/bug-hurd/2012-07/msg00051.html + i mean, why do you think they could be due to that? + the error is that both strong and weak refs in a port are 0 when + adding a reference + weak refs are almost never used so let's forget about them + when a ref count drops to 0, the port is automatically deallocated + so what other than memory corruption setting this counter to 0 + could possibly do that ? :) + one could also guess an unbalanced ref/unref logic, somehow + what do you mean ? + that for a bug, an early return, etc a port gets unref'ed often + than it is ref'ed + highly unlikely, as they're protected by a lock + pinotree: ah you mean, the object gets deallocated early because + of an deref overflow ? + pinotree: could be, yes + pinotree: i wonder if it could happen because of the periodic sync + duplicating the node table without holding references + rah, libports uses a big lock in many places :( + braunr: yes, i meant that + we could try using libduma some day + i wonder if it could work out of the box + but that wouldn't help to find out whether a port gets deref'ed + too often, for instance + although it could be adapted to do so, i guess + 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]]. -- cgit v1.2.3