

![Hero](/images/circular-refs-kotlin/hero.png)

Circular object references can be dangerous. They break code at runtime, and are difficult to guard against at compile time.

Consider the following example:

```kotlin
data class Driver(val name: String, val teamId: String)

data class Team(val id: String, val drivers: List<Driver>)

object Drivers {
  val LewisHamilton: Driver = Driver("Sir Lewis Hamilton", Teams.Mercedes.id)
}

object Teams {
  val Mercedes: Team = Team("merc", listOf(Drivers.LewisHamilton))
}

fun main() {
  println(Drivers.LewisHamilton)
  println(Teams.Mercedes)
}
```

Although innocuous at first glance, **this code breaks Kotlin's non-nullable types**.

If you run this example on [Kotlin Playground](https://pl.kotl.in/Pri2qj09N), it produces the following output:

```text
Driver(name=Sir Lewis Hamilton, teamId=merc)
Team(id=merc, drivers=[null])
```

A `null` value snuck into a non-nullable type.

## How?

Kotlin `object`s are lazily initialized[^1].

`LewisHamilton` gets initialized upon its first-access in `main`. Its constructor references another lazy variable `Mercedes`, whose constructor has a circular reference to `LewisHamilton`.

Therefore, constructor of `Mercedes` references a yet-uninitialized `LewisHamilton` variable, and leads to a null value being stored in a non-nullable variable.

While this is bug is easy to fix, the problem is that this code fails at runtime, thus **silently breaking Kotlin's non-null types**.

Consider starring this issue to get more attention to this problem: [KT-44633: Circular object references silently break Kotlin's non-nullable types ](https://youtrack.jetbrains.com/issue/KT-44634)

## More Circular Reference Madness

Let's look at a few more examples to illustrate problems with circular references.

```kotlin
data class Foo(var bar: Bar? = null)

data class Bar(var foo: Foo? = null)

fun main() {
  val foo = Foo()
  val bar = Bar()
  foo.bar = bar
  bar.foo = foo

  println(foo)
}
```

This code produces a `StackoverflowError`. You can try it [here](https://pl.kotl.in/wJdoP8NQ6).

`println` calls `toString()` on `foo`. Since `Foo` is a data class, its `toString()` implementation calls the same method on its member properties too. This leads to an ever growing call-stack.

```
⤷ `Foo.toString()`
  ⤷ `Bar.toString()`
    ⤷ `Foo.toString()`
      ⤷ `Bar.toString()`
        ⤷ `Foo.toString()`
          ⤷ ...
```

A simpler, more condensed version of the same problem can be illustrated as follows:

```kotlin
data class CircularRef(var ref: CircularRef? = null)

fun main() {
    val circularRef = CircularRef()
    circularRef.ref = circularRef
    println(circularRef)
}
```

This code again produces a `StackoverflowError`, as `CircularRef.toString()` continues recursing forever. Try it [here](https://pl.kotl.in/cDfjeEkd7).

## Not just Kotlin

The problem of Circular References plagues other languages too. Here's an example of the same code in Go.

```go
type Foo struct {
	BarRef *Bar
}

func (f *Foo) String() string {
	return fmt.Sprintf("Foo { BarRef: %v }", f.BarRef)
}

func (b *Bar) String() string {
	return fmt.Sprintf("Bar { FooRef: %v }", b.FooRef)
}

type Bar struct {
	FooRef *Foo
}

func main() {
	foo := Foo{}
	bar := Bar{}
	foo.BarRef = &bar
	bar.FooRef = &foo
	fmt.Println(foo)
	fmt.Println(bar)
	fmt.Println("Finished")
}
```

Note circular references in the `String()` method on both interfaces. Run this [here](https://play.golang.com/p/4VlvFjfFkNm).

This code never prints _Finished_. While the execution timeout on _play.golang.org_ prevents this code from running for long, the same code on my local machine prints: `fatal error: stack overflow`.

## Conclusion

Be on the look out for circular references in your Kotlin code. You will receive no compile time errors or warnings about them.

If you would like to change that, consider starring this issue: [KT-44634: Circular object references silently break Kotlin's non-nullable types](https://youtrack.jetbrains.com/issue/KT-44634).

---

[^1]: https://kotlinlang.org/docs/reference/object-declarations.html#object-declarations

_Thanks to Subhrajyoti Sen for reviewing this post!_

---

_Question, comments or feedback? Feel free to reach out to me on Twitter [@haroldadmin](https://twitter.com/haroldadmin)_


Exploration of how circular references break null-safety in Kotlin

Breaking Kotlin's Null-Safety with Circular References



![Hero](/images/finding-right-path/hero.png)

On a recent project, I got the opportunity to create a desktop application using [Electron](https://electronjs.org), [React](https://reactjs.org) and [Go](https://golang.org). Electron served as a tool to bundle the React app and the Go server in a neat little installable package. It also took care of starting the Go server as a subprocess when the app launched.

The included Go server performed a few dependency checks at each startup by trying to find some particular executables in the `PATH`.

```go
func checkDependency(cmd string) bool {
  _, err := exec.LookPath(cmd)
  return err == nil
}
```

This worked great during the development period, but once I built an installable package and installed the app, these dependency checks failed every time I launched it.

_Curiously, the checks only failed only on MacOS and Linux, not on Windows._

_Even more curiously, launching the installed app through a terminal seemingly fixed this problem._

The reason for this behaviour, as I found out after several hours of painful debugging, was unexpected inheritance of the `PATH` environment variable.

## Inheritance of Environment Variables

**A newly spawned child process inherits its parent's environment variables.**

To demonstrate this, let's build a couple of Go programs: `envReader` and `envParent`.

`envReader` reads a special environment variable _"SpecialEnv"_ and prints its value, or _"\<Not Found\>"_ if it is not set.

```go
// envReader
func main() {
  val := os.Getenv("SpecialEnv")
  if val == "" {
    val = "<Not Found>"
  }
  fmt.Printf("%d: SpecialEnv: %s", os.Getpid(), val)
}
```

`envParent`, runs `envReader` as a subprocess twice, with the "SpecialEnv" set only in the second invocation.

```go
// envParent
func main() {
  fmt.Println("Before setting special env:")
  runChild()

  fmt.Println("Setting SpecialEnv in parent")
  os.Setenv("SpecialEnv", "SpecialValue")

  fmt.Println("After setting special env:")
  runChild()
}

func runChild() {
  child := exec.Command("envReader")
  output, _ := child.Output() // Error handling omitted for brevity
  fmt.Println(string(output))
}
```

This produces the following output:

```shell
Before setting special env:
62231: SpecialEnv: <Not Found>

Setting SpecialEnv in parent

After setting special env:
62232: SpecialEnv: SpecialValue
```

In the first invocation, _"SpecialEnv"_ is not set and hence the produced output contains _"\<Not Found\>"_. After this, the parent calls `os.Setenv` and sets a value to it. Note that this value is not exported, so it is _local to the `envParent` processes only_[^1]. Yet, the second invocation of the child process finds it successfully.

This proves that child processes inherit their parent's environment variables.

## Inherited PATH outside the Terminal

During development, it is common to launch Electron apps using the `electron` command from a terminal. This creates a new process and starts the app. Since this process is spawned from a terminal shell, it inherits all the environment variables of the shell session. This includes any custom variables defined in shell config files such as `.bashrc` and `.bash_profile`, like a custom `PATH`.

Once the app is shipped, consumers don't use the terminal to launch it. They use GUI icons, which means the app process is not created by a terminal, but by the Desktop Environment.

The desktop environment process does not concern itself with custom configuration files such as `.bash_profile`, hence its version of the `PATH` environment variable is terse. It does not contain any custom directories the user might have specified in their shell config files.

To show this in action, I wrote a small app with [fyne](https://github.com/fyne-io/fyne) which shows the `PATH` value of the current process. You can find the source [here](https://gist.github.com/haroldadmin/73dc2ca674aaf566c02fe66109b2f859), if interested.

Here's what it looks like when launched from the **GUI**:

![PATH when launched from GUI](/images/finding-right-path/from-gui.png)

And here it is when launched from the **terminal**:

![PATH when launched from Terminal](/images/finding-right-path/from-terminal.png)

Clearly, we're missing out on a lot when our app is launched from the GUI.

(_Also, I really need to cleanup my PATH config_)

## Finding the correct PATH

Fortunately, this problem is easy to solve. With the help of the user's default shell, we can find the complete PATH with the `env` command.

- All processes have access to the `SHELL` environment variable, which contains the location of the default shell executable (eg, _"/bin/bash"_)
- Most shells support the `env` command to list all the environment variables they have access to
- Therefore, running the default shell in an interactive, login mode[^2] with the `env` command should give us, among other variables, the complete PATH.

The Go implementation of this is not too complicated:

```go
func fixPath() {
  // Find the default shell
  defaultShell := os.Getenv("SHELL")

  // Prepare command to get all environment variables
  // eg. /bin/bash -ilc env
  envCommand := exec.Command(defaultShell, "-ilc", "env")
  allEnvVars, _ := envCommand.Output()

  // Find the PATH variable
  for _, envVar := range strings.Split(string(allEnvVars), "\n") {
    if strings.HasPrefix(envVar, "PATH") {
      currentPath := os.Getenv("PATH")
      // Append retrieved PATH to existing value, to get the complete PATH
      completePath := currentPath + string(os.PathListSeparator) + envVar
      // Set the current process's PATH to the complete PATH
      os.Setenv("PATH", completePath)
      return
    }
  }
}
```

I have created a small Go package which do this, and a little more: [_pathfix_](https://github.com/haroldadmin/pathfix).

To use it, add it to your project with `go get github.com/haroldadmin/pathfix`, and then call the `Fix` method to fix your process's PATH:

```go
pathfix.Fix()
```

<br />

Here it is in action, using the app shown earlier.

_Before the fix:_

![Before fix](/images/finding-right-path/before-fix.png)

_After the fix:_

![After fix](/images/finding-right-path/after-fix.png)

If you need to do it in Electron using NodeJS, there is a handy package [_fix-path_](https://github.com/sindresorhus/fix-path) for it.

## Some Notes

- After fixing this problem, I wondered why didn't I encounter this error on Windows. I suspect that Environment Variables on Windows are global by default, and hence every process receives the same `PATH` value every time. I might be wrong about this, please feel free to correct me.

- I also stumbled across PAM Environment Variables which are apparently a more "correct" way of solving this on Linux. You can read more about them in the [documentation](http://www.linux-pam.org/Linux-PAM-html/sag-pam_env.html) and the [Arch Wiki](https://wiki.archlinux.org/index.php/Environment_variables#Using_pam_env). The gist of it is that you need to define your environment variables in a `pam_env` file, but the syntax for it is different. I would be grateful if someone took the time out to explain their usage in a more approachable manner.

- Another potential solution for Linux users is to define their environment variables in the `~/.profile` file, which is sourced by the OS shell on every login. However, just like with the `pam_env` solution, this puts the burden of configuration on your users instead of you.

---

_Question, comments or feedback? Feel free to reach out to me on Twitter [@haroldadmin](https://twitter.com/haroldadmin)_

[^1]: Bash environment variables should be declared with `export` to make them available to other processes. eg., `export PATH=$PATH:~/Android/Sdk/platform-tools/`
[^2]: Using the `-il` options when launching the shell makes sure that it reads common config files, such as `*.rc` and `*.profile`. The `-c` at the end just makes sure that the shell reads only the `env` command, and nothing more. Read more about interactive, non-interactive, login and non-login shells [here](https://unix.stackexchange.com/questions/38175/difference-between-login-shell-and-non-login-shell)


Fixing the PATH environment variable inherited by child processes from their parents

# Go