[Bug libc/22157] New: getcwd() returns EINVAL(22) instead of ENOENT

["dkumar at mvista dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=22157

            Bug ID: 22157
           Summary: getcwd() returns EINVAL(22) instead of ENOENT
           Product: glibc
           Version: unspecified
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: libc
          Assignee: unassigned at sourceware dot org
          Reporter: dkumar at mvista dot com
                CC: drepper.fsp at gmail dot com
  Target Milestone: ---

Created attachment 10431
  --> https://sourceware.org/bugzilla/attachment.cgi?id=10431&action=edit
Test Program and strace log

Hi,

Sometimes getcwd() returns EINVAL error instead of ENOENT.

I have come accross a scenario like below,

Under Test Program, mlockall(MCL_FUTURE)  is called and after that repeatedly 
getcwd(NULL, 66000)  is called and "errno" is checked if getcwd() returns NULL.

Now, under script below steps are executed,


################
count=1
maxcount=999999

mkdir  thr_getcwd_testdir/
cd  thr_getcwd_testdir/
rm -rf  ../thr_getcwd_testdir/

while [ $count -le $maxcount ];
do
  ../thr_getcwd  ===>>> program which calls mlockall() and then getcwd(()
  if [ "$?" != "0" ] ; then
      exit 1
  fi
done
################


Here, current directory is deleted but it's handle is still present.
What is expected is getcwd() should have set errno to ENOENT but errno
is set to EINVAL.

After going through the glibc code flow looks like below,

getcwd() 
   => __getcwd() => malloc() 
   => getcwd()[syscall] ---> This sets errno as ENOENT.
   => free() => __libc_free() => _int_free() => heap_trim() 
   => shrink_heap() => __madvise() 
   => madvise()[syscall] ---> This sets errno as EINVAL because of mlockall().

So eventhough getcwd() sets correct errono but madvise() changes that and due
to that application receives wrong errno.

Same is confirmed via strace, which is attached with the bug.
       $ strace  -f  -o  strace.txt  ./thr_getcwd.sh

We have even attached Test Program to reproduce the issue.

Running test program,
        $ tar -xzvf  thr_getcwd.tgz
        $ ./thr_getcwd.sh

Please suggest if above scenario should be considered as bug or not.


Thanks!
Dhiraj

-- 
You are receiving this mail because:
You are on the CC list for the bug.