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