on OSX, debugging (w gdb or lldb) a nim program crashes at the 1st call to execCmdEx

[timotheecour]

BUG:can't debug (with lldb) a nim binary that calls execCmdEx

lldb /tmp/nim//app
(lldb) target create "/tmp/nim//app"
(lldb) r
Process 98697 launched: '/tmp/nim/app' (x86_64)
ok1b.1
/Users/timothee/git_clone/nim/timn/bugs/stdlib/t22_lldb_execCmdEx.nim(12) t22_lldb_execCmdEx
/Users/timothee/git_clone/nim/timn/bugs/stdlib/t22_lldb_execCmdEx.nim(9) test
/Users/timothee/git_clone/nim/Nim/lib/pure/osproc.nim(1330) execCmdEx
/Users/timothee/git_clone/nim/Nim/lib/pure/streams.nim(280) readLine
/Users/timothee/git_clone/nim/Nim/lib/pure/streams.nim(162) readChar
/Users/timothee/git_clone/nim/Nim/lib/pure/streams.nim(87) readData
/Users/timothee/git_clone/nim/Nim/lib/pure/streams.nim(413) fsReadData
/Users/timothee/git_clone/nim/Nim/lib/system/sysio.nim(80) checkErr
/Users/timothee/git_clone/nim/Nim/lib/system/sysio.nim(72) raiseEIO
/Users/timothee/git_clone/nim/Nim/lib/system.nim(2970) sysFatal
Error: unhandled exception: Unknown IO Error [IOError]
Process 98697 exited with status = 1 (0x00000001)
(lldb) ^D

import osproc

proc test=
  echo "ok1b.1"
  let temp = "brew --version".execCmdEx()
  echo "ok1b.2"
  echo temp
test()

I'm on OSX
(note: can't use gdb because of https://stackoverflow.com/questions/52529838/gdb-8-2-cant-recognized-executable-file-on-macos-mojave-10-14)

that's very annoying because it makes it impossible to debug some programs, in case they're calling execCmdEx somewhere

[Araq]

So ... submit a bug report to your debugger?

[timotheecour]

it works fine in C++ so the issue is how it's done in Nim, it seems to me

#include <cstdio>
#include <iostream>
#include <memory>
#include <stdexcept>
#include <string>
#include <array>

std::string exec(const char* cmd) {
    std::array<char, 128> buffer;
    std::string result;
    std::shared_ptr<FILE> pipe(popen(cmd, "r"), pclose);
    if (!pipe) throw std::runtime_error("popen() failed!");
    while (!feof(pipe.get())) {
        if (fgets(buffer.data(), 128, pipe.get()) != nullptr)
            result += buffer.data();
    }
    return result;
}

int main(){
  auto ret = exec("date");
  std::cout << "ret:" << ret << std::endl;
}

lldb /tmp/D20181107T193702
(lldb) target create "/tmp/D20181107T193702"
Current executable set to '/tmp/D20181107T193702' (x86_64).
(lldb) r
Process 65884 launched: '/tmp/D20181107T193702' (x86_64)
ret:Wed Nov  7 20:44:33 PST 2018

Process 65884 exited with status = 0 (0x00000000)
(lldb)

[krux02]

lldb is not officially supported, only gdb.

[timotheecour]

• unfortunately gdb doesn't work on OSX on latest OS (mojave), as I mentioned above link

I just tried on ubuntu 18.10 to see what works and what doesn't, here's the results:

• ubuntu 18.10:

  • it works with gdb
  • it works with lldb (installed via sudo apt-get install lldb or even via brew install llvm --with-lldb, both being at lldb version 7.0.0)

• OSX (latest, Mojave: 10.14)

  • gdb itself doesn't work
  • it crashes with lldb (as shown above)

so there's currently no way to debug on latest OSX a Nim program that involves a call to execCmdEx :(

/cc @krux02 @Araq
or anyone, if you have an older version of OSX, would you mind trying with gdb on OSX to see if it crashes (as with lldb) or not? so as to isolate what the problem is; thanks!

[timotheecour]

update:

• I used macincloud to try on previous version of OSX (high sierra, 10.13.6); instead of latest (Mojave)
  unfortunately I can't codesign since instructions to codesign require rebooting with recovery mode and that seems impossible on macincloud (see https://gist.github.com/danisfermi/17d6c0078a2fd4c6ee818c954d2de13c#gistcomment-2773820), but a workaround was to use sudo gdb instead of gdb)
  it turns out it also throws for both lldb (illdb-1000.0.38.2) and gdb (which I had to backport to 8.0.1 according to https://stackoverflow.com/questions/49222683/how-do-i-install-gdb-on-macos-10-13-3-high-sierra)

• then I finally managed to make gdb work on OSX on Mojave and patched homebrew formula for it:
  brew install https://raw.githubusercontent.com/timotheecour/homebrew-timutil/master/gdb_tim.rb

/cc @Araq @krux02
the result is that gdb also throws, so the bug is not specific to lldb, it's on both (lldb and gdb) on OSX

[alaviss]

Can you try compiling your example with -d:useFork?

[timotheecour]

I tried, it makes no difference in what I'm observing.
Note:
regardless of gdb/lldb/(-d:useFork or not), I'm observing that it crashes most of the time, and, a small fraction of the times it doesnt':

(lldb) r
Process 96526 launched: '/tmp/nim/app' (x86_64)
ok1b.1
/Users/timothee/git_clone/nim/timn/tests/nim/all/t0047.nim(12) t0047
/Users/timothee/git_clone/nim/timn/tests/nim/all/t0047.nim(9) test
/Users/timothee/git_clone/nim/Nim/lib/pure/osproc.nim(1337) execCmdEx
/Users/timothee/git_clone/nim/Nim/lib/pure/streams.nim(280) readLine
/Users/timothee/git_clone/nim/Nim/lib/pure/streams.nim(162) readChar
/Users/timothee/git_clone/nim/Nim/lib/pure/streams.nim(87) readData
/Users/timothee/git_clone/nim/Nim/lib/pure/streams.nim(413) fsReadData
/Users/timothee/git_clone/nim/Nim/lib/system/sysio.nim(80) checkErr
/Users/timothee/git_clone/nim/Nim/lib/system/sysio.nim(72) raiseEIO
/Users/timothee/git_clone/nim/Nim/lib/system.nim(2969) sysFatal
Error: unhandled exception: Unknown IO Error [IOError]
Process 96526 exited with status = 1 (0x00000001)
(lldb) r
Process 96794 launched: '/tmp/nim/app' (x86_64)
ok1b.1
ok1b.2
(output: "Homebrew 1.8.4-55-ge659ce9\nHomebrew/homebrew-core (git revision 7f34c; last commit 2018-12-12)\nHomebrew/homebrew-cask (git revision da193; last commit 2018-12-12)\n", exitCode: 0)
Process 96794 exited with status = 0 (0x00000000)

[alaviss]

Looks like your C++ code does not feature any kind of error checking. Can you try to duplicate Nim's error checking behavior if fgets returns NULL?

[timotheecour]

I don't think it's relevant but here you go, see [1].
As discussed in #9953, the problem happens earlier, the bug is inside:
var p = startProcess(...) which likely messes the input/output stream of the child process

[1]

clang++ -o /tmp/D20181107T193702  -std=c++14 -g -ferror-limit=7 $timn_D/tests/nim/all/t0041.cpp

/tmp/D20181107T193702
fgets null
ferror was 0
ret:{}

#include <cstdio>
#include <iostream>
#include <memory>
#include <stdexcept>
#include <string>
#include <array>

std::string exec(const char* cmd) {
    std::array<char, 128> buffer;
    std::string result;
    std::shared_ptr<FILE> pipe(popen(cmd, "r"), pclose);
    if (!pipe) throw std::runtime_error("popen() failed!");
    auto f = pipe.get();
    while (!feof(f)) {
        #if 1
        // works
        if (fgets(buffer.data(), 128, f) != nullptr){
            result += buffer.data();
        } else {
            std::cout << "fgets null" << std::endl;
            if(ferror(f)){
              perror("custom err");
              clearerr(f);
            } else{
                printf("ferror was 0\n");
            }
        }
        #else
        // auto result = fread(buffer.data(), 1, len, f)
        char ci;
        auto temp = fread(&ci, 1, 1, f);
        // auto temp = fread(buffer.data(), 1, 1, f);
        std::cout << "temp:" << temp << std::endl;
        std::cout << "f:" << f << std::endl;
        #endif
    }
    return result;
}

int main(){
  auto ret = exec("'/Applications/Sublime Text.app/Contents/SharedSupport/bin/subl'");
  std::cout << "ret:{" << ret << "}" << std::endl;
  return 0;
}

[timotheecour]

@alaviss this PR #9987 gives a little bit more insight:

with that PR I know that the error is Interrupted system call (instead of Unknown IO Error)

/Users/timothee/git_clone/nim/vitanim/testcases/tests/t0001.nim(73) t0001
/Users/timothee/git_clone/nim/vitanim/testcases/tests/t0001.nim(51) test
/Users/timothee/git_clone/nim/Nim/lib/pure/osproc.nim(1337) execCmdEx
/Users/timothee/git_clone/nim/Nim/lib/pure/streams.nim(280) readLine
/Users/timothee/git_clone/nim/Nim/lib/pure/streams.nim(162) readChar
/Users/timothee/git_clone/nim/Nim/lib/pure/streams.nim(87) readData
/Users/timothee/git_clone/nim/Nim/lib/pure/streams.nim(413) fsReadData
/Users/timothee/git_clone/nim/Nim/lib/system/sysio.nim(106) checkErr
/Users/timothee/git_clone/nim/Nim/lib/system/sysio.nim(74) raiseEIO
/Users/timothee/git_clone/nim/Nim/lib/system.nim(2969) sysFatal
Error: unhandled exception: strerror: `Interrupted system call` [IOError]

[timotheecour]

ok that improved msg from my PR really helps seeing light: see https://stackoverflow.com/questions/4959524/when-to-check-for-eintr-and-repeat-the-function-call/4960077#4960077

[timotheecour]

adding high priority because it blocks debugging applications that (somewhere deep down) call execCmdEx + friends