http://bugzilla.novell.com/show_bug.cgi?id=627972 http://bugzilla.novell.com/show_bug.cgi?id=627972#c0 Summary: getcwd(2) returns bogus path Classification: openSUSE Product: openSUSE 11.1 Version: Final Platform: x86-64 OS/Version: Other Status: NEW Severity: Critical Priority: P5 - None Component: Kernel AssignedTo: bnc-team-screening@forge.provo.novell.com ReportedBy: koenig@linux.de QAContact: qa@suse.de Found By: --- Blocker: --- recently we updated the kernel from 2.6.27.45-0.1.1 to 2.6.27.48-0.1.1, my $HOME is mounted via autofs. now, for the 1st time, I notice the following strange problems with some shell scripts: for one (of many open;) xterm and the bash within /bin/pwd now returns "koenig/dir" instead of "/home/koenig/dir" in other bash instances which are in the same dir (note esp. the missing / for the broken /bin/pwd output!). in other xterm/bash instances this does not happen at all, while it's 100% reproducable in that one bash. "strace /bin/pwd" shows that that bad string directly comes from getcwd(2): good bash: getcwd("/home/koenig/dir", 4096) = 17 bad bash: getcwd("koenig/dir", 4096) = 11 a "cd $PWD" or "cd subdir" fixes the problem for this shell, but not the parent process/shell (same for interactive shells/tests): $ bash -c "/bin/pwd" koenig/dir $ bash -c "cd $PWD ; /bin/pwd" /home/koenig/dir $ bash -c "cd subdir ; /bin/pwd" /home/koenig/dir/subdir $ /bin/pwd koenig/dir more facts: "stat ." show identical output in shells with good and broken pwd output. that directory is a quite old dir, it was not removed/recreated/renamed/whatsoever in the last decade /home is ext3fs this happend twice today in two different directories! in both cases the 1st error was from acroread (it claims "ERROR: Cannot determine current directory."). for the 1st problem I just did "cd $PWD" (thinking about some "rm dir ; mkdir dir" problem), for the 2nd occurance I started some more testing to see what's coing on. we installed that new kernel on July 29, so it's only running now for 2 office days with at least 2 instances of this new(?) behaviour. autofs did not change recently (install date Mar 16 2009) /proc/self/cwd shows the same broken information for that bash process: lrwxrwxrwx 1 koenig s+c 0 Aug 3 17:55 cwd -> koenig/dir dmesg doesn't show any error or (to me) significant output a closer look at the strace output shows more weird differences: the st_ino=... return value for all stat() and fstat() calls differ. surprisingly, the strace of the "bad" /bin/pwd shows the correct st_ino vaules (compared with "ls -i file" and "stat file" in both a broken and good bash instance -- all show the same inode numbers!) any idea what's going on here ? any problem in the new kernel, like some weird memory corruption or similar ? I'll run a full fsck on that partition overnight -- just in case.... -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.