Nixpkgs: neovim: Should statically link against jemalloc on OSX

[jamessan]

Issue description

When dynamically linking to jemalloc on OSX, neovim can encounter this jemalloc bug --
https://github.com/jemalloc/jemalloc/issues/895. Static linking somehow avoids that jemalloc bug, thus preventing people from running into issues like https://github.com/neovim/neovim/issues/5681 and https://github.com/neovim/neovim/issues/6972.

We're changing neovim to prefer static linkage for jemalloc on OSX, but that won't be released soon. It may be worthwhile to change the NixOS package to static link.

Also, there was some concern that the upstream change could break the part of the package build that changes the path to the dynamic library.

[ilovezfs]

Corresponding change in Homebrew: https://github.com/Homebrew/homebrew-core/pull/15393

[0xABAB]

@jamessan As indicated in https://github.com/jemalloc/jemalloc/issues/895#issuecomment-313786483, there is no issue (other than a program design failure in the case of neovim).

This is just guessing a solution based on incomplete analysis. As such, I kindly request you to close this issue again.

It will likely take a single person at least one week of work to fix Neovim, if not much more (since the issue is already open for at least one month). Nobody needs to fix jemalloc.

People working on Nixpkgs certainly have no business fixing this problem.

[jamessan]

As indicated in jemalloc/jemalloc#895 (comment), there is no issue (other than a program design failure in the case of neovim).

Your comment in that issue is quite vague. What documentation are you referring to? What behavior is expected?

I would be glad to look at fixing Neovim if it were clear that the problem was with Neovim. There has been no response to the jemalloc issue that it isn't a jemalloc problem, so I don't see why you're so quick to say it isn't.

[ilovezfs]

@0xABAB I agree with you that neovim should be fixed such that it can work with jemalloc dylib if possible. But in the meantime, until/unless that happens, it's usually best to distribute software that works if there are known workarounds that are effective.

[0xABAB]

@jamessan The burden of proof is on the reporter of an issue to show there is a problem. Sometimes a crashing program is that, sometimes it is not. In this case it is not.

I am referring to the documentation related to all the symbols used in that program. So, there are relevant POSIX standards, MacOSX platform documentation, etc.

@ilovezfs Except you are likely wrong. It will likely also break in the statically linked case, even though your tests say that it won't. It only tells me that your tests are not good enough or that you are lucky.

If you loved your users, you would warn them about possible data loss and data corruption, not make them happy with something which is nothing more than an illusion.

[jamessan]

The burden of proof is on the reporter of an issue to show there is a problem. Sometimes a crashing program is that, sometimes it is not. In this case it is not.

Sure, I get that, but just saying "Something is wrong with your program, go away." doesn't help either. I'm open to any information that can help resolve the issue rather than work around it.

The original reporter of the issue has a pretty simple program that illustrates the problem, so is there something that's clearly wrong with that program?

[0xABAB]

@jamessan You claim that the semantics of that program is simple and that's exactly where you are wrong. It's not simple, because otherwise someone didn't take the time to write it and you wouldn't be asking me, right?

I didn't give the advice for nothing. If you cannot prove that a particular program should work, what's there to discuss? Why even open an issue in the first place?

I could tell you what's wrong in detail, but that would take quite some time to write down and even then I have my doubts whether or not you would recognize what I would say as correct; it would likely result in another round of questions.

It would also send the wrong message; that I will debug the problems that others create carelessly. I want programmers to think before they write down a program. If that's too much to ask, I'd rather have these programs full of bugs, such that users will flock to other programs with fewer or no problems.

[matthewbauer]

@jamessan
We're still using jemalloc v4.5.0. Are you sure that it is actually affected?

Perhaps we need input from Nix users that are vim users just to verify that it is the case.

/cc @garbas @lnl7

[ilovezfs]

@matthewbauer https://github.com/jemalloc/jemalloc/issues/895#issue-234350118

It seems to at least affect >= 4.5.0

[garbas]

@jamessan @matthewbauer probably best would be to just include the patch directly from GitHub as Homebrew did it.

[jamessan]

Or would it be better to include jemalloc's fix?

[teto]

This can be closed since jemalloc is going to be removed in future versions c2343180d74f547d99abcc3c4979a9ebb047af17