GDB reports exit code 01, program was supposed to return 0.

[ginnedup]

Please use the following bug reporting template to help produce issues which are actionable and reproducible, including all command-line steps necessary to induce the failure condition. Please fill out all the fields! Issues with missing or incomplete issue templates will be closed.

If this is a console issue (a problem with layout, rendering, colors, etc.), please post to the console issue tracker.

Important: Do not open GitHub issues for Windows crashes (BSODs) or security issues. Please direct all Windows crashes and security issues to [email protected]. Ideally, please configure your machine to capture minidumps, repro the issue, and send the minidump from "C:\Windows\minidump".\

See our contributing instructions for assistance.

Please fill out the below information:

• Your Windows build number: (Type ver at a Windows Command Prompt)
  10.0.17763

• What you're doing and what's happening: (Copy&paste the full set of specific command-line steps necessary to reproduce the behavior, and their output. Include screen shots if that helps demonstrate the problem.)
  Wrote a bare-bones C program (just the main() header and "return 0;"), compiled it, then ran it in gdb (version GNU gdb (Ubuntu 8.1-0ubuntu3) 8.1.0.20180409-git) with "gdb -q test" (test is the executable).
  I then just typed "run" at the gdb prompt, and it came back with:
  Starting program: test
  [Thread debugging using libthread_db enabled]
  Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
  [Inferior 1 (process 209) exited with code 01]

• What's wrong / what should be happening instead:
  I believe the last line should read, "[Inferior 1 (pid) exited normally.]", since the only line in main() was "return 0". Note that this also happens with every other C executable I've made. Interestingly, this does NOT happen when running in a VirtualBox VM with Linux Mint guest. The "...exited normally" wording does appear in that environment. The above problem does not seem to prevent the C programs from running at all, it's just an erroneous message from GDB.

• Strace of the failing command, if applicable: (If some_command is failing, then run strace -o some_command.strace -f some_command some_args, and link the contents of some_command.strace in a gist here).
  gdb.strace.txt
  (I couldn't copy the contents from WSL to the gist page for some reason...)

• For WSL launch issues, please collect detailed logs.
  This is not a WSL launch issue.

[therealkenc]

Can't repro here with WSL1 on what I've got, which is contemporaneous Insiders. Do appreciate the strace(1) log (thanks!), but unfortunately tracing gdb is fraught (note "Could not trace the inferior process" in there).

10.0.17763

Could try 1909 aka 19H2 aka 18363 November 2019 Update.

[ginnedup]

Just upgraded to 18363, but the problem still occurs, plus a little extra now:
Starting program: test
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
==45==LeakSanitizer has encountered a fatal error.
==45==HINT: For debugging, try setting environment variable LSAN_OPTIONS=verbosity=1:log_threads=1
==45==HINT: LeakSanitizer does not work under ptrace (strace, gdb, etc)
[Inferior 1 (process 45) exited with code 01]

[ginnedup]

Update: I tried recompiling without the -fsanitize=address option, and now I see the expected message upon program completion:
Starting program: test
[Inferior 1 (process 133) exited normally]

So based on what I mentioned in the previous comment, I'm guessing that the reason for the exit code 01 happening all the time was some problem with the address sanitizer in WSL. Some quick googling did show that there were prior problems with address sanitizer in WSL:
gcc --sanitize doesnt work (missing stuff from procfs prevents address-sanitizer from working) duplicate
#1898 by LewisPringle was closed on Apr 10
ASAN doesn't work fixedin1803
#121 by tycho was closed on May 22, 2018
valgrind doesn't work fixedin1803
#120 by tycho was closed on Feb 14, 2017
(and 5 other closed issues)

Maybe there's some regression, or a new problem with ASAN?

[therealkenc]

Maybe there's some regression, or a new problem with ASAN?

No linux-behavior. Hint is the "LeakSanitizer does not work under ptrace (strace, gdb, etc)".

[ginnedup]

I noticed you included the WSL Linux version in your pics, and realized I hadn't included that info in my comments, so here it is:
$ cat /proc/version
Linux version 4.4.0-18362-Microsoft ([email protected]) (gcc version 5.4.0 (GCC) ) #476-Microsoft Fri Nov 01 16:53:00 PST 2019

I tried upgrading Ubuntu itself, but it there doesn't seem to be a new release to go to:
$ sudo -S env RELEASE_UPGRADER_NO_SCREEN=1 do-release-upgrade
[sudo] password for :
Checking for a new Ubuntu release
There is no development version of an LTS available.
To upgrade to the latest non-LTS develoment release
set Prompt=normal in /etc/update-manager/release-upgrades.

[therealkenc]

The second screencap is native Linux Ubuntu (kernel happens to be 5.3.0-23-generic). It doesn't matter which version of WSL you are on because the "...exited with code 01" is Linux behavior. Likewise it won't matter what version of Ubuntu you are on (Bionic, Cosmic, Disco, Eoan).

To upgrade to the latest non-LTS develoment release
set Prompt=normal in /etc/update-manager/release-upgrades.

^--- That, if you want the latest non-LTS development release. Which, all things being equal, you probably don't.

[ginnedup]

By "Linux behavior", do you mean to say that that's just how Linux normally does things? I would've thought that the fact that this doesn't happen in a VirtualBox VM with Linux Mint guest would suggest otherwise, though my knowledge and experience in this area are lacking, so I'm far from certain about that.
And yes, I'm pretty sure I don't want the non-LTS version.

[therealkenc]

By "Linux behavior", do you mean to say that that's just how Linux normally does things?

Yes. See also "==7817==HINT: LeakSanitizer does not work under ptrace (strace, gdb, etc)" message in the Normal™ Linux screencap above. LeakSanitizer encountered a fatal error, which appears to be reflected in a nonzero gdb exit. That cap is from Normal Ubuntu (by chance Eoan) running on metal.

I would've thought that the fact that this doesn't happen in a VirtualBox VM with Linux Mint

You would think that correctly. And if you were running Mint in WSL and not Ubuntu (and if all the other stars were aligned identically between the two runs) maybe that would be the case on WSL too. But you aren't, so it isn't.

What's different about your Mint rig such that the error doesn't appear? Couldn't tell you because I'm not running your Mint rig. Tracking down the difference in star alignment would be a pretty unsatisfying exercise (you'll discover "oh right, that").

You can get what amounts to the same experience on Ubuntu (on WSL or otherwise) it appears with "export ASAN_OPTIONS=detect_leaks=0".

[ginnedup]

ASAN_OPTIONS=detect_leaks=0

That would seem to defeat the purpose of using ASAN in the first place, so nah, I think I'm good with not doing that.

And since you confirmed my thinking about "Linux behavior", I'm guessing that means there's nothing to be done about this, right?

[therealkenc]

And since you confirmed my thinking about "Linux behavior", I'm guessing that means there's nothing to be done about this, right?

Pretty much, with the scare quotes noted, absent identifying a diverge. Which would probably be a pretty unsatisfying exercise.

Leave the issue float open for a bit if you want. Someone might step up with a explaination I haven't considered, even if this is (scare quote) "Linux behavior" and there is no WSL 1 actionable (to the extent you weren't punted to WSL 2 even if there were an actionable). I'd feel better about this one if I could just tell you: "you aren't seeing the behavior on your Mint rig because reason".

[ginnedup]

Fair enough. I'll leave this issue open for the time being, say the next few weeks/months (I don't know how this would affect any issue-closing metrics on your part). I'll get emails if anyone else drops in with info since I authored the issue, and check in every so often in case someone else raises a similar issue. Thanks for your help, I appreciate your taking the time to look into this!