> Quite true, but what if dn_set_mtime is set before the test, and set again
> immediately after it? Then it would be cleared, although the time value
> stored in the timespec would be a bit out of date (as the mapped time is
> read out before the test). Is this something to care about?
Not at al
On Sat, Dec 02, 2000 at 11:32:56PM -0500, Roland McGrath wrote:
> > > It matters to understand whether or not that code is going to
> > > eventually call set_node_times before it matters that the mtime update
> > > be reflected. If so, then it doesn't matter whether that mtime update
> > > happen
> On Thu, Nov 23, 2000 at 10:34:53PM -0500, Roland McGrath wrote:
> > The first thing to figure out is what the code path looks like that reaches
> > getblk when it sets dn_set_mtime there (I think it should be
> > pager_unlock_page that is doing it, but you should check).
>
> pager_unlock_page a
On Thu, Nov 23, 2000 at 10:34:53PM -0500, Roland McGrath wrote:
> The first thing to figure out is what the code path looks like that reaches
> getblk when it sets dn_set_mtime there (I think it should be
> pager_unlock_page that is doing it, but you should check).
pager_unlock_page and diskfs_gr
Roland McGrath <[EMAIL PROTECTED]> writes:
> instead of the separate tests done now (and same for the other two). That
> way, dn_set_mtime is only touched if it was just acted upon--if it gets set
> right after the test, then it will remain set for later. Then it would be
> safe to just remove
The first thing to figure out is what the code path looks like that reaches
getblk when it sets dn_set_mtime there (I think it should be
pager_unlock_page that is doing it, but you should check). It matters to
understand whether or not that code is going to eventually call
set_node_times before i
Hi,
On Thu, Nov 23, 2000 at 07:57:08PM -0500, Roland McGrath wrote:
> > This seems to be some race condition betweenm the sync thread and other
> > dn_set_?time mangling stuff.
>
> I would tend to agree. Notice for example thread 3, which appears to be a
> peropen in the process of dying. Tha
On Thu, Nov 23, 2000 at 08:26:42PM -0500, Roland McGrath wrote:
> It looks to me like the ext2fs block allocation code (getblk.c) can set
> dn_set_mtime when called from the pager whiled not holding the node lock.
> It will hold node->dn->alloc_lock, but that is all.
I think what you say is corre
It looks to me like the ext2fs block allocation code (getblk.c) can set
dn_set_mtime when called from the pager whiled not holding the node lock.
It will hold node->dn->alloc_lock, but that is all.
The ext2_getblk code is called sometimes with the node lock held
(storeinfo.c, diskfs_grow) and som
> This seems to be some race condition betweenm the sync thread and other
> dn_set_?time mangling stuff.
I would tend to agree. Notice for example thread 3, which appears to be a
peropen in the process of dying. That is probably the temacs open file
descriptor on the file being written, being
On Thu, Nov 23, 2000 at 07:13:51PM -0500, Roland McGrath wrote:
> Please try to get a stack trace from the assertion failure. You could
> attach gdb in noninvasive mode and hit it, or you could just hack the code
> to use glibc's backtrace (execinfo.h) function and print it out rather than
> usin
Hi,
here is the stack trace.
Marcus
--
`Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED]
Marcus Brinkmann GNUhttp://www.gnu.org[EMAIL PROTECTED]
[EMAIL PROTECTED]
http://www.marcus-brinkmann.de
Script started on Fri Nov 24 00:40:47 2000
hurd:~#
Please try to get a stack trace from the assertion failure. You could
attach gdb in noninvasive mode and hit it, or you could just hack the code
to use glibc's backtrace (execinfo.h) function and print it out rather than
using assert.
___
Bug-hurd mai
Package: hurd
Version: N/A
Severity: normal
Hi,
building the Debian emacs20 package triggers an assertion failure in
ext2fs/inode.c (write_node):
assert (!np->dn_set_ctime && !np->dn_set_atime && !np->dn_set_mtime);
This happens when temacs dumps the emacs binary. It does only happen with a
14 matches
Mail list logo
