00:45:14  * AtumTquit (Remote host closed the connection)
10:25:09  * mylesborinsquit (Quit: farewell for now)
10:25:39  * mylesborinsjoined
11:44:20  * ryzokukenjoined
13:14:36  * AtumTjoined
16:18:08  * whitlockjcjoined
16:18:13  <whitlockjc>Hello all!
16:28:35  * whitlockjcquit (Quit: Page closed)
17:03:03  * whitlockjcjoined
19:08:32  * erikjquit (Ping timeout: 245 seconds)
19:14:25  * erikjjoined
19:14:25  * erikjquit (Changing host)
19:14:25  * erikjjoined
19:15:01  * omninonsensequit (Read error: Connection reset by peer)
20:54:25  * whitlockjcquit (Quit: Page closed)
22:54:22  * brett19quit (Ping timeout: 264 seconds)
22:59:18  * brett19joined
23:12:24  * whitlockjcjoined
23:17:27  * cjihrigjoined
23:18:16  <cjihrig>whitlockjc ping
23:18:24  <whitlockjc>pong
23:18:59  <whitlockjc>So...on non-OS X *nix boxes, the btime test is always failing. I'm trying to have someone else look into this to see if I'm wrong but I think that `uv_fs_req_cleanup` isn't doing what it's suppose to.
23:19:28  <cjihrig>i saw an email, but then the comment was deleted, and then another comment. do you mean the statbuf?
23:19:38  <whitlockjc>https://github.com/libuv/libuv/pull/590/files#diff-54b530892931c350c937210c2284374eR710
23:20:08  <whitlockjc>Yes. I think since we are reusing the same req for all tests that a previous statbuf is lingering so when stat is called during the test, it's getting details from a previous call.
23:20:35  <whitlockjc>On non-macOS *nix, there is NO WAY that the birthtime should ever be altered so the stat should show the original birthtime...but it's not.
23:22:19  <cjihrig>the statbuf isn't a pointer, just a struct holding a bunch of numbers. it's not cleaned up between calls. i would have thought that subsequent calls would overwrite it though
23:23:29  <whitlockjc>That's what I saw but it _seems_ to be lingering only because when calling `uv_fs_utime_ex` before, the same btime passed is in the `uv_fs_stat` call.
23:24:43  * joocain2quit (Ping timeout: 255 seconds)
23:27:18  <whitlockjc>I could be wrong but there is no way this should be happening.
23:28:12  <whitlockjc>I'm not sure how `uv_fs_stat` can come up with a value that isn't possible. If I use stat from the CLI, it shows the appropriate time that is not what the test was attempting to set. In fact, the test can try to set whatever it wants but for non-macOS *nix, utime is used and it doesn't use btime nor can it alter it.
23:28:14  <whitlockjc>Super confusing.
23:28:48  <whitlockjc>What's interesting is on Windows it appears to be failing due to the same thing.
23:29:24  <whitlockjc>And since I copied the working uv_utime and uv_futime tests, I would figure it would just work. It did before merging to master. ;)
23:29:40  <whitlockjc>s/merge/rebasing/
23:29:55  * ryzokukenquit (Remote host closed the connection)
23:30:01  <whitlockjc>I hope it's something stupid I did. :)
23:31:52  <cjihrig>is NAN getting passed anywhere it shouldn't be?
23:32:40  <whitlockjc>No. I've updated the tests to no longer use math.h since other OSes didn't support it properly (SmartOS, ...). I'm using -1 now.
23:33:54  <whitlockjc>In the CI builds, some *nix boxes were complaining about NAN and/or isnan. Just simplified things to remove it.
23:34:08  <whitlockjc>It was only used once, by this new function for checking utime results.
23:34:08  * joocain2joined
23:38:16  <cjihrig>just out of curiosity, do the tests pass if you don't reuse the same request struct?
23:39:48  <whitlockjc>I think I was wrong about that. Looking at it, check_utime_ex runs its own `uv_fs_stat` and does not reuse the `req`. But...that should be impossible.
23:48:57  <cjihrig>nothing is jumping out at me at the moment. i'm not really in a position to try to debug too much right now (on vacation), but i'm happy to work through this with you if you can't get to the bottom of it
23:49:37  <whitlockjc>No worries. I've been stumped on this for a bit. I've tried various things and I don't see an execution path that makes this even possible, yet it's happening. ;)
23:49:40  <whitlockjc>Enjoy your vacation.
23:49:49  <cjihrig>thanks :-D