Results of stat() incorrect, don't match statSync

[hildjj]

Head of git a of Tue Jul 26 17:30:06 UTC 2011, v0.5.2-13-g09ee293.

fs.statSync() is correct.
fs.sync(), not so much, including isDirectory() as a follow-on.

This breaks npm almost completely.

{ dev: 234881026,
ino: 32870552,
mode: 16877,
nlink: 15,
uid: 0,
gid: 0,
rdev: 0,
size: 510,
blksize: 4096,
blocks: 0,
atime: Mon, 25 Jul 2011 14:27:29 GMT,
mtime: Wed, 20 Jul 2011 20:15:51 GMT,
ctime: Wed, 20 Jul 2011 20:15:51 GMT }
require('fs').stat('/usr', function (er, s) { console.log(er), console.log(s); });

> null
> { dev: 234881026,
> ino: 999917,
> mode: 37016,
> nlink: 501,
> uid: 0,
> gid: 0,
> rdev: 0,
> size: 0,
> blksize: 0,
> blocks: 1307990819,
> atime: Thu, 01 Jan 1970 00:00:00 GMT,
> mtime: Thu, 01 Jan 1970 00:00:00 GMT,
> ctime: Thu, 01 Jan 1970 00:00:00 GMT }```

[bnoordhuis]

What OS is this? Works fine on Linux 2.6.32.

[hildjj]

Whoops, sorry. OSX 10.7 "Lion". Just released, which is why it's not surprising there are features that don't work as designed. I wonder if the background file I/O thread has different privileges or something.

[bnoordhuis]

It's been reported that your test case works okay with 0.4.10 on Lion (thanks, xerox!). Can you pinpoint the offending commit with git bisect? I don't have a Lion machine at my disposal.

[koichik]

@xenyou also tested on the "Lion", but there is no problem. very strange...

https://gist.github.com/1105515

[idmillington]

Getting the same problem (which is preventing npm from installing). I'm still on Snow Leopard. statSync works, stat gives me bad data.

[idmillington]

Incidentally for anyone happening across this in an attempt to install npm, the simplest approach is to roll back to node 0.4(.9) - git checkout v0.4.9 - then remake and install.

[bnoordhuis]

@idmillington: does fs.stat() work on 0.4.9? If so, can you give this a spin?

$ rm -rf build/default/deps/lib{ev,eio} build/default/src/*.o
$ curl -s https://github.com/joyent/node/commit/220e228.patch | git am
$ make install

[rmustacc]

As extra data points: On Mac OS X 10.6.8, with the head of the node v0.4 branch I'm getting the correct behavior. On illumos with head of node v0.4, I'm also getting the correct behavior.

[arlolra]

this is the offending commit:
6b78b6b

as far as i can tell

[arlolra]

a little more info. i'm on 10.6.8, with xcode 4

v0.4.10 works
v0.5.0 works
v0.5.1 fail

a little testing shows the clang issue above

[xenyou]

FYI, Mac OS X 10.6.8 with Xcode 3.2.3 (Macbook)

V0.5.1 works.
latest(git) works.

[idmillington]

@bnoordhuis - yes it does. I'm on the road today, but I'll do the binary search on versions when I get back if it hasn't already been found - though @arlolra seems to have a candidate now.

[arlolra]

if you revert 6b78b6b on v0.5.2, it works just fine

[bnoordhuis]

@arlolra: Thanks for investigating. Are CC and CXX set in your environment?

[arlolra]

I had tried CC=gcc CXX=g++ ./configure and got the same problem.

But python; import os; os.environ does not show CC / CXX ... so, no, I don't think they are.

However, I just tried adding them to the environment and rebuilding, and got the same problem.

Tried clang too with no success.

[hildjj]

Status?

[bnoordhuis]

Does it still happen with the latest master? The fs code has changed considerably (for one, it all lives in libuv now).

[hildjj]

Now I get a core:

require('fs').statSync('/tmp')
zsh: segmentation fault (core dumped)

Backtrace isn't terribly interesting:

(gdb) bt
#0 0x0000000100058d95 in v8::HandleScope::RawClose ()
#1 0x000000010000f717 in node::Stat ()
#2 0x0000000100074bbe in v8::internal::Builtin_HandleApiCall ()
Previous frame inner to this frame (gdb could not unwind past this frame)

[bnoordhuis]

Unfortunate coincidence, that was an unrelated bug that got fixed yesterday. Can you try again with the latest master? Please do a make distclean first to clean out stale build files.

[hildjj]

Another crash. Same backtrace. I deleted my entire repo and built from scratch.

[arlolra]

test/simple/test-fs-stat.js passes for me on v0.5.7-pre
so i think it's resolved

but a lot of other tests fail :)

[hildjj]

Again, this is on OSX Lion, 10.7.1. I'm building with homebrew; brew install --HEAD node, but I got the same core when I built by hand in a separately cloned copy.

[arlolra]

oh. well, i'm not on lion but i believe the problem discussed above was more about clang and xcode 4. i could be wrong.

[bnoordhuis]

Yes. I suspect that clang is either producing bad code or it's exposing a bug in node. The thing is that it doesn't happen with clang's bleeding edge (rev 137028) on linux.

[hildjj]

With today's head, 'make test' yields 100% of the test cases failing with: --- CRASHED ---.

[arlolra]

Incorrect result of stat() is no longer an issue on OS X Lion. You can close.

[bnoordhuis]

Just tested and indeed it works fine.