Hacker News Reader

Comment by masklinn | Hacker News Reader

Previously on setenv being a terrible thing: https://www.evanjones.ca/setenv-is-not-thread-safe.html (discussion: https://news.ycombinator.com/item?id=38342642 first comment is even about it causing issues in Rust)

View on HN

Yes. That's known.

Most of the rest of the problem here seems to be the development environment. They're testing on a remote machine in an Amazon data center and using Docker. This rig fails to report that a process has crashed. Then they don't have enough debug symbol info inside their container to get a backtrace. If they'd gotten a clean backtrace reported on the first failure, this would have been obvious.

Why is anyone using "setenv" anyway?

Yup, it's mostly just the story and tools we used to get ourselves out of a mess that was made harder by some decisions made earlier -- the tests were running in a container with stripped symbols (we're going to ship symbols after this, no reason to over-optimize), our custom test runner failed to report process death (an oversight).

There's no reason setenv should have been called here. The `openssl-probe` library could simply return the paths to the system cert files and callers could plug those directly into the OpenSSL config.

Oversights all around and hopefully this continues to improve.

> Yup, it's mostly just the story and tools we used to get ourselves out of a mess that was made harder by some decisions made earlier -- the tests were running in a container with stripped symbols (we're going to ship symbols after this, no reason to over-optimize)

It's worth noting here that you can also build your binaries and keep debug symbols separately.

You don't need to ship them with the binary (although it will make many scenarios a bit simpler if you do, since you'll always have the right ones available).

Some info that might help: https://www.tweag.io/blog/2023-11-23-debug-fission/ https://undo.io/resources/gdb-watchpoint/reduce-binary-size-...

> we're going to ship symbols after this, no reason to over-optimize

You might want to look into debuginfod.

> Why is anyone using "setenv" anyway?

Because it’s there and it looks like a good idea until it takes one of your fingers.

It really does not look like a good idea to setenv() . The very notion is quite terrifying. Messing with a bunch of globals, that other code knows about as well? Nuh-uh.

The thing is, the OP people weren't doing that at all, it was some irresponsible library maintainers. If your code does that, you have to include something like the "surgeon general's warning" everywhere: "CAREFUL: USING THIS LIBRARY MAY CAUSE TERMINAL CRASHES".

It's OpenSSL. It's basically a sea urchin turned into code in terms of safe handling.

Agreed.

History: V7 research UNIX had "getenv()", but not "setenv()".[1] BSD Unix 4.x had "getenv()" and "setenv()"[2] Google's "AI Overview" says "The setenv() and unsetenv() functions were included in Version 7 of AT&T UNIX.", but that does not seem to be correct.

This misfeature seems to be what was once called a "Berkeleyism", a Berkeley mod to UNIX.

"setenv()" predates UNIX/Linux getting threads.

[1] http://web.cuzuco.com/~cuzuco/v7/v7vol1.pdf

[2] https://archive.org/details/44bsdprogrammers0000ucbe/page/n3...

Sadly, it's often the only way to adjust certain behaviors of certain libraries.

I think you're confusing setting the environment before running a process, with setting the environment _within_ the process. If you're running a shell session, or even a compiled process which is just a "runner" for some other process - then certainly, we all do "export SOME_SETTING=value" and run things. But if you're writing a C library, which could well be used in a multi-threaded environment - you don't need to "adjust" anything, and should not invoke setenv. If your library is not pleased with the settings of another library, then it should start returning errors, or even exit() if you're a violent kind of a guy - but not setenv().

Reply on news.ycombinator.com