open_issues/glibc: truncate/ftruncate.

2 files changed, 64 insertions, 84 deletions

diff --git a/hurd/translator/mtab/discussion.mdwn b/hurd/translator/mtab/discussion.mdwn
index 2e7999f5..3fb6974c 100644
--- a/hurd/translator/mtab/discussion.mdwn
+++ b/hurd/translator/mtab/discussion.mdwn
@@ -2221,23 +2221,6 @@ In context of [[open_issues/mig_portable_rpc_declarations]].
     <braunr> which is why i'm mentioning it
     <braunr> :)
     <braunr> i'll try to reproduce the assertion
-    <pinotree> libdiskfs/node-drop.c:      assert (np->dn_stat.st_size == 0); ←
-      this one?
-    <braunr> yes
-    <braunr> hm no
-    <pinotree> oho
-    <braunr> no, not that one
-    <pinotree> no-oho
-    <braunr> well maybe by side effect
-    <braunr> but i doubt it
-    <pinotree> iirc you constantly get that when building ustr
-    <braunr> (e.g., because the object was freed and reallocated quickly,
-      st_size has been reset, something like that)
-    <braunr> is ustr a package ?
-    <pinotree> yes
-    <braunr> ok
-    <braunr> thanks
-    <braunr> pinotree: indeed, it's still present
     <braunr> pinotree: actually, after a more in-depth look, reference counting
       looks valid before the fix too
     <pinotree> ok, thanks for checking
@@ -2247,65 +2230,10 @@ In context of [[open_issues/mig_portable_rpc_declarations]].
     <braunr> malloc
     <pinotree> ok
     <braunr> i suspect the code doesn't handle memory failure well
-    <pinotree> iirc the ustr tests are mostly disk-intensive
-    <braunr> this one is really about enonmem
-    <braunr> enomem
-    <braunr> i'll make ext2fs print a stack trace
-    <pinotree> (might be wrong, but did not investigate further, sorry)
-    <braunr> no worries
-    <braunr> i'm doing it now :)
 
 
 ### IRC, freenode, #hurd, 2013-10-02
 
-    <braunr> i've traced the problem up to truncate
-    <braunr> which gets a negative size
-    <braunr> shouldn't take long to find out where it comes from now
-    <pinotree> it seems our truncate doesn't handle negative values well though
-    <braunr>        EINVAL The argument length is negative or larger than the
-      maximum file size.
-    <braunr> i still have to see whether it comes from the user (unlikely) or
-      if it's an internal inconsistency
-    <braunr> i suspect some code wrongly handles vm_map failures
-    <braunr> leading to that inconsistency
-    <braunr> pinotree: looks like glibc doesn't check for length >= 0
-    <pinotree> yeah
-    <braunr> servers should do it nonetheless
-    <pinotree> should we fix glibc, libdiskfs/libnetfs/libtrivfs/etc, or both?
-    <braunr> it appears a client does the truncate
-    <braunr> i'd say both
-    <braunr> can you take the glibc part ? :)
-    <pinotree> i was going to do the hurd part... :p
-    <pinotree> ok, i'll pick libc
-    <braunr> well i'm doing it already
-    <braunr> i want to write a test case first
-    <braunr> to make sure that's the problem
-    <pinotree> already on the hurd part, you mean?
-    <braunr> yes
-    <pinotree> ok
-    <braunr> ok looks like it
-    <pinotree> would you share the test you are doing, so i don't need to write
-      it again? :)
-    * pinotree lazy
-    <braunr> :)
-    <braunr> as soon as darnassus is restarted
-    <pinotree> ideally we could have some repository with all the testcases
-      written over time to fix bugs in implementations/compatibility/etc
-    <braunr> i noticed the system doesn't automatically reboot when e2fsck says
-      reboot, and no unexpected inconsistency was found
-    <braunr> is that normal ?
-    <pinotree> or having something like posixtestsuite, but actively maintained
-    <braunr> pinotree: polishing the test before sending it
-    <pinotree> sure, no hurry :)
-    <braunr> i can't reproduce the assertion but it does make ext2fs freeze
-    <braunr> pinotree: http://darnassus.sceen.net/~rbraun/test_ftruncate.c
-    <pinotree> merci
-    <braunr> pinotree: ustr builds
-    <pinotree> wow
-    <braunr> the client code (ustr) seems to perform a ftruncate with size
-      ((size_t)-1) whereas lengths are signed ..
-    <braunr> i'll check other libraries and send a patch soon
-
     <teythoon_> braunr: btw, did you fix the leak?
     <braunr> yes
     <braunr>
@@ -2325,18 +2253,6 @@ In context of [[open_issues/mig_portable_rpc_declarations]].
       had my development vm running on that patches for two weeks
 
 
-### IRC, freenode, #hurd, 2013-10-03
-
-    <braunr> youpi: i've committed a fix to hurd that checks for negative sizes
-      when truncating files
-    <braunr> this allows building the ustr package without making ext2fs choke
-      on an assertion
-    <braunr> pinotree is preparing a patch for glibc
-    <braunr> see truncate/ftruncate
-    <braunr> with an off_t size parameter, which can be negative
-    <braunr>        EINVAL The argument length is negative or larger than the
-      maximum file size.
-    <braunr> hurd servers were not conforming to that before my change
 
 
 ## Multiple mtab Translators Spawned
diff --git a/open_issues/glibc.mdwn b/open_issues/glibc.mdwn
index 23339bac..f2dc3159 100644
--- a/open_issues/glibc.mdwn
+++ b/open_issues/glibc.mdwn
@@ -1864,6 +1864,70 @@ Last reviewed up to the [[Git mirror's 0323d08657f111267efa47bd448fbf6cd76befe8
           type for some flock structure field)
         <youpi> s/by/be/
 
+  * `truncate`/`ftruncate`
+
+    Hurd fixed with 2013-10-03 commit 6c3825f2b750bf9b913c6ea986739e648c470603,
+    glibc still to be done?
+
+    IRC, freenode, #hurd, 2013-10-01:
+
+        <pinotree> libdiskfs/node-drop.c:      assert (np->dn_stat.st_size == 0); ←
+          this one?
+        <pinotree> iirc you constantly get that when building ustr
+        <braunr> is ustr a package ?
+        <pinotree> yes
+        <pinotree> iirc the ustr tests are mostly disk-intensive
+
+    IRC, freenode, #hurd, 2013-10-02:
+
+        <braunr> i've traced the problem up to truncate
+        <braunr> which gets a negative size
+        <braunr> shouldn't take long to find out where it comes from now
+        <pinotree> it seems our truncate doesn't handle negative values well though
+        <braunr>        EINVAL The argument length is negative or larger than the
+          maximum file size.
+        <braunr> i still have to see whether it comes from the user (unlikely) or
+          if it's an internal inconsistency
+        <braunr> i suspect some code wrongly handles vm_map failures
+        <braunr> leading to that inconsistency
+        <braunr> pinotree: looks like glibc doesn't check for length >= 0
+        <pinotree> yeah
+        <braunr> servers should do it nonetheless
+        <pinotree> should we fix glibc, libdiskfs/libnetfs/libtrivfs/etc, or both?
+        <braunr> it appears a client does the truncate
+        <braunr> i'd say both
+        <braunr> can you take the glibc part ? :)
+        <pinotree> i was going to do the hurd part... :p
+        <pinotree> ok, i'll pick libc
+        <braunr> well i'm doing it already
+        <braunr> i want to write a test case first
+        <braunr> to make sure that's the problem
+        <pinotree> already on the hurd part, you mean?
+        <braunr> yes
+        <pinotree> ok
+        <braunr> ok looks like it
+        <braunr> i can't reproduce the assertion but it does make ext2fs freeze
+        <braunr> pinotree: http://darnassus.sceen.net/~rbraun/test_ftruncate.c
+        <pinotree> merci
+        <braunr> pinotree: ustr builds
+        <pinotree> wow
+        <braunr> the client code (ustr) seems to perform a ftruncate with size
+          ((size_t)-1) whereas lengths are signed ..
+        <braunr> i'll check other libraries and send a patch soon
+
+    IRC, freenode, #hurd, 2013-10-03:
+
+        <braunr> youpi: i've committed a fix to hurd that checks for negative sizes
+          when truncating files
+        <braunr> this allows building the ustr package without making ext2fs choke
+          on an assertion
+        <braunr> pinotree is preparing a patch for glibc
+        <braunr> see truncate/ftruncate
+        <braunr> with an off_t size parameter, which can be negative
+        <braunr>        EINVAL The argument length is negative or larger than the
+          maximum file size.
+        <braunr> hurd servers were not conforming to that before my change
+
   * Verify baseline changes, if we need any follow-up changes:
 
       * a11ec63713ea3903c482dc907a108be404191a02