3.4.7: segmentation fault when cwd goes missing

[asottile]

The backtrace points at getcwd returning NULL here:

libsass/src/file.cpp

Line 58 in 5b9572e

std::string cwd = getcwd(wd, wd_len);

The trace I have is:

[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
============================= test session starts ==============================
platform linux -- Python 3.6.3, pytest-3.3.0, py-1.5.2, pluggy-0.6.0
rootdir: /tmp/libsass-python, inifile:
collected 91 items                                                             

sasstests.py ........................................................... [ 64%]
...............................
Program received signal SIGABRT, Aborted.
0x00007ffff6cd2428 in __GI_raise (sig=sig@entry=6)
    at ../sysdeps/unix/sysv/linux/raise.c:54
54	../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) where
#0  0x00007ffff6cd2428 in __GI_raise (sig=sig@entry=6)
    at ../sysdeps/unix/sysv/linux/raise.c:54
#1  0x00007ffff6cd402a in __GI_abort () at abort.c:89
#2  0x00007ffff2c7184d in __gnu_cxx::__verbose_terminate_handler() ()
   from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#3  0x00007ffff2c6f6b6 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#4  0x00007ffff2c6f701 in std::terminate() ()
   from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#5  0x00007ffff2c6f919 in __cxa_throw ()
   from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#6  0x00007ffff2c9814f in std::__throw_logic_error(char const*) ()
   from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#7  0x00007ffff30d3044 in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char const*> (
    this=this@entry=0xfd3a68, __beg=__beg@entry=0x0, __end=<optimized out>)
    at /usr/include/c++/5/bits/basic_string.tcc:216
#8  0x00007ffff30d313e in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct_aux<char const*> (
    __end=<optimized out>, __beg=0x0, this=0xfd3a68)
    at /usr/include/c++/5/bits/basic_string.h:195
#9  std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char const*> (__end=<optimized out>, __beg=0x0, 
    this=0xfd3a68) at /usr/include/c++/5/bits/basic_string.h:214
#10 std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string (__a=..., __s=0x0, this=0xfd3a68)
    at /usr/include/c++/5/bits/basic_string.h:456
#11 Sass::File::get_cwd[abi:cxx11]() () at libsass/src/file.cpp:58
#12 0x00007ffff3063908 in Sass::Context::Context (this=0xfd3a60, c_ctx=...)
    at libsass/src/context.cpp:89
#13 0x00007ffff3179ee8 in Sass::File_Context::File_Context (ctx=..., 
    this=0xfd3a60) at libsass/src/context.hpp:125
#14 sass_compile_file_context (file_ctx=file_ctx@entry=0xfd4770)
    at libsass/src/sass_context.cpp:462
#15 0x00007ffff318bb77 in PySass_compile_filename (self=<optimized out>, 
    args=<optimized out>) at pysass.cpp:592
#16 0x00000000004b34b9 in _PyCFunction_FastCallKeywords ()
#17 0x0000000000544e1e in ?? ()
#18 0x0000000000546e9d in _PyEval_EvalFrameDefault ()
#19 0x0000000000544a85 in ?? ()
#20 0x0000000000544d37 in ?? ()
#21 0x0000000000546b0b in _PyEval_EvalFrameDefault ()
#22 0x0000000000544a85 in ?? ()
#23 0x000000000054599e in PyEval_EvalCodeEx ()
#24 0x0000000000489dd6 in ?? ()
#25 0x0000000000456d9c in PyObject_Call ()
#26 0x0000000000548b9a in _PyEval_EvalFrameDefault ()
#27 0x0000000000544a85 in ?? ()
#28 0x000000000054599e in PyEval_EvalCodeEx ()
---Type <return> to continue, or q <return> to quit---Quit

I believe this only affects the 3.4.x branch (from what I can tell the non-windows branch of get_cwd is dead code since cwd was pushed to wrappers in 3.5.x).

Let me know if you want a more targetted reproduction

The rough pseudo code to reproduce this is:

touch test.scss
F="$PWD/test.scss"
mkdir wat
cd wat
rmdir ../wat
sassc "$F"

[mgreter]

FWIW. ruby sass quits with the following error:

Errno::ENOENT: No such file or directory - getcwd
  Use --trace for backtrace.

[mgreter]

Closed via #2529