On Sun, 2009-12-20 at 16:35 -0800, Ryan Niebur wrote:
> Hi Ben,
>
> thanks for the response.
>
> On Mon, Dec 21, 2009 at 12:12:44AM +0000, Ben Hutchings wrote:
> > On Sun, 2009-12-20 at 15:46 -0800, Ryan Niebur wrote:
> > > Package: linux-image-2.6-parisc64
> >
> > Yes but which version?
> >
>
> the version that paer is running (apparently
> linux-image-2.6.32-trunk-parisc64 2.6.32-1)
Wow, already? OK.
> and whatever version peri is running.
>
> > > Severity: important
> > > Blocks: 558981
> > >
> > > The attatched minimal test case shows these results:
> > >
> > > on my i386 machine, it correctly gives two different numbers:
> > > $ gcc test.c; ./a.out
> > > First: 1
> > > Second: 2
> > >
> > > however on paer.debian.org (hppa):
> > > $ gcc test.c; ./a.out
> > > First: 1
> > > Second: 1
> > >
> > > Based on the manpage of inotify_add_watch, it sounds like the correct
> > > behavior is to have different numbers. It seems that the author of
> > > inotify-tools also interpreted it that way.
> > >
> > > This bug is causing my package's tests to fail, which causes it to FTBFS:
> > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=558981
> >
> > I think the test case is broken; why should two watches that don't exist
> > at the same time have unique ids? You might as well test:
> >
>
> the manpage makes it sound like it should be unique for each
> filename. and if the test case is broken, then I don't understand why
> this only fails on hppa.
I'm saying there is no guarantee in the manual page about what order
watch ids will be assigned in, and that it is unreasonable to expect
"unique" to mean "unique among all watches that ever existed for this
handle". The assignments could vary depending on the architecture or on
the phase of the moon. The test cases should not make any assertions
about them, other than that any two watches *that exist at the same
time* have different ids.
However, it does look like the implementation is intended to assign
sequential ids, so this may indicate a bug in the implementation. But
it shouldn't block you.
> > fd1 = open("foo", O_RDONLY);
> > close(fd1);
> > fd2 = open("bar", O_RDONLY);
> > assert(fd2 != fd1);
> >
>
> and you would expect this assertion to fail on all architectures, yes?
> however my test only fails on hppa.
In a single-threaded program, yes. Otherwise, who knows? But open() is
specified to use the lowest currently unused entry in the file
descriptor table, whereas inotify_add_watch() can use any currently
unused id - including the one just removed.
Ben.
--
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.
Attachment:
signature.asc
Description: This is a digitally signed message part