patchelf-0.17.2 seems to corrupt emacs on staging-next
#482
Comments
|
Thanks for reporting the issue. I think I will be able to reproduce the issue easily using nix, but if you could attach the result of |
|
Using It's gist st change of traversal from for (auto & i : replacedSections) {
const std::string & sectionName = i.first;
auto & shdr = findSectionHeader(sectionName);to /* We iterate over the sorted section headers here, so that the relative
position between replaced sections stays the same. */
for (auto & shdr : shdrs) {
std::string sectionName = getSectionName(shdr);
auto i = replacedSections.find(sectionName);
if (i == replacedSections.end())
continue;I suspect it has a chance to miss newly added sections if Attaching
Looks like one of program headers got lost (or merged into existing one): diff -u readelf-aw-good.txt readelf-aw-bad.txt | cat
--- readelf-aw-good.txt 2023-03-18 18:30:42.604009844 +0000
+++ readelf-aw-bad.txt 2023-03-18 18:31:55.812435119 +0000
@@ -10,11 +10,11 @@
Version: 0x1
Entry point address: 0x427ea0
Start of program headers: 64 (bytes into file)
- Start of section headers: 6757680 (bytes into file)
+ Start of section headers: 6753584 (bytes into file)
Flags: 0x0
Size of this header: 64 (bytes)
Size of program headers: 56 (bytes)
- Number of program headers: 15
+ Number of program headers: 14 |
|
I debugged something like this. It had to do with rounding of load segments overlapping. |
|
I think this is the same scenario I saw in: #446 We can see the following LOAD segments with different read/write permissions: The first one goes from Notice that the alignment is
There is an overlap between the two. So the fix #469 should hopefully fix this issue. |
|
I tried --- a/pkgs/applications/editors/emacs/generic.nix
+++ b/pkgs/applications/editors/emacs/generic.nix
@@ -46,6 +46,7 @@
else "lucid")
, withSystemd ? lib.meta.availableOn stdenv.hostPlatform systemd, systemd
, withTreeSitter ? lib.versionAtLeast version "29", tree-sitter ? null
+, patchelfUnstable
}:
assert (libXft != null) -> libpng != null; # probably a bug
@@ -135,7 +136,7 @@ assert withTreeSitter -> tree-sitter != null;
""
];
- nativeBuildInputs = [ pkg-config makeWrapper ]
+ nativeBuildInputs = [ pkg-config makeWrapper patchelfUnstable ]
++ lib.optionals (srcRepo || withMacport) [ texinfo ]
++ lib.optionals srcRepo [ autoreconfHook ]
++ lib.optional (withX && (withGTK3 || withXwidgets)) wrapGAppsHook;
diff --git a/pkgs/development/tools/misc/patchelf/unstable.nix b/pkgs/development/tools/misc/patchelf/unstable.nix
index 66c14bd07e0..3f20cb7834f 100644
--- a/pkgs/development/tools/misc/patchelf/unstable.nix
+++ b/pkgs/development/tools/misc/patchelf/unstable.nix
@@ -2,13 +2,13 @@
stdenv.mkDerivation rec {
pname = "patchelf";
- version = "unstable-2023-03-07";
+ version = "unstable-2023-03-18";
src = fetchFromGitHub {
owner = "NixOS";
repo = "patchelf";
- rev = "ea2fca765c440fff1ff74e1463444dea7b819db2";
- sha256 = "sha256-IH80NcLhwjGpIXEjHuV+NgaSC+Y/PXquxZ/C8Bl+CLk=";
+ rev = "265b31ae22c6e1d20b01295aaa7bcf28fd31a5cf";
+ sha256 = "sha256-+iGvdjXvhk5mN8jp3u+M9fICKFqbtyZCx+WjQszaB1o=";
};
# Drop test that fails on musl (?) |
|
NixOS/nixpkgs#221900 was merged into |
|
Weird, I can't reproduce the crash using the commit before the merge. (I'm new to Nix, so I might be doing something wrong) I can reproduce the messages from |
|
I reverted it locally and now I can reproduce it. Not sure what is the difference, but let me get to it. |
|
This commit fails for me (it's the one directly preceeding the This should allow extracting exact binary: |
|
Note so far:
Still investigating. Looks like the |
|
I'm quite sure the missing thing is an Line 1015 in 265b31a When we enter that if, we split a LOAD segment in two: the one the loads the replaced sections and the one that keeps loading the sections that stay in place. It's a bit hard though to nail the exact fix |
|
I think we should revert the patchelf default on |
|
I wonder if you'd want to get a jobset on Hydra to verify a full nixpkgs rebuild before a (stable?) patchelf release is made. (or possibly even on a PR/branch if it's considered risky) This certainly isn't the first time we had to revert the default, e.g. I found NixOS/nixpkgs#69213 |
This reverts commit 6d1fadf, reversing changes made to 8cfd131. NixOS/patchelf#482 (comment)
That would be lovely. I can see that Patchelf has accumulated fixes without an associated test. It's a bit painful to recover from that and being able to verify all nix packages will certainly help a lot. Perhaps we should add "ldd" test after patching anything because it catches several issues. |
485: Resize segment mapping rewritten sections if needed #482 r=Mic92 a=brenoguim Co-authored-by: Breno Rodrigues Guimaraes <[email protected]>
|
I have now bumped patchelf to 0.18.0 in a branch based on nixpkgs staging and my emacs seems to be no longer corrupted. |
|
pcloud seems to be affected by this as well - what's curious, when compiled with patchelfUnstable, it crashes inside ld-linux-x86-64.so.2! i.e. doing: diff --git a/pkgs/applications/networking/pcloud/default.nix b/pkgs/applications/networking/pcloud/default.nix
index 403d1e0cf34..93e9eb9b1d1 100644
--- a/pkgs/applications/networking/pcloud/default.nix
+++ b/pkgs/applications/networking/pcloud/default.nix
@@ -34,6 +34,7 @@
, libXdamage
, nss
, udev
+, patchelfUnstable
}:
let
@@ -62,6 +63,7 @@ stdenv.mkDerivation {
nativeBuildInputs = [
autoPatchelfHook
+ patchelfUnstable
];
buildInputs = [... and then: ... results in: eu-elflint also seems to have an issue with one of the files there: This issue seems to exist on all patchelf versions available in nixpkgs now (i.e. patchelf 0.13, 0.15 and unstable-2023-04-25 all generate invalid libnode.so's, which seems to have been somewhat exacerbated by NixOS/nixpkgs#209870 since it now additionally links |
|
fwiw, it looks like pcloud (x86-64_linux) got (more) broken by #469 - i.e. doing: diff --git a/pkgs/applications/networking/pcloud/default.nix b/pkgs/applications/networking/pcloud/default.nix
index 403d1e0cf34..93e9eb9b1d1 100644
--- a/pkgs/applications/networking/pcloud/default.nix
+++ b/pkgs/applications/networking/pcloud/default.nix
@@ -34,6 +34,7 @@
, libXdamage
, nss
, udev
+, patchelfUnstable
}:
let
@@ -62,6 +63,7 @@ stdenv.mkDerivation {
nativeBuildInputs = [
autoPatchelfHook
+ patchelfUnstable
];
buildInputs = [
diff --git a/pkgs/development/tools/misc/patchelf/unstable.nix b/pkgs/development/tools/misc/patchelf/unstable.nix
index 7d340cf547b..987f6bb8860 100644
--- a/pkgs/development/tools/misc/patchelf/unstable.nix
+++ b/pkgs/development/tools/misc/patchelf/unstable.nix
@@ -2,13 +2,13 @@
stdenv.mkDerivation rec {
pname = "patchelf";
- version = "unstable-2023-04-25";
+ version = "unstable";
src = fetchFromGitHub {
owner = "NixOS";
repo = "patchelf";
- rev = "008a582741617e2d7d5aa4aab1e8ddfdec0067d9";
- sha256 = "sha256-SC9zZbHN1p5BD6YHr+/ZNelmmZDozEO/vDwuCdJJCcs=";
+ rev = "27cbc89d4830d5ae1fe3a2396f2a6042266895bc";
+ sha256 = "sha256-FxwKznM/xcYZAmeKMAKYA2qkED4Zfayr62R7cg8AORA=";
};
# Drop test that fails on musl (?)... generates a file that crashes over diff --git a/pkgs/applications/networking/pcloud/default.nix b/pkgs/applications/networking/pcloud/default.nix
index 403d1e0cf34..93e9eb9b1d1 100644
--- a/pkgs/applications/networking/pcloud/default.nix
+++ b/pkgs/applications/networking/pcloud/default.nix
@@ -34,6 +34,7 @@
, libXdamage
, nss
, udev
+, patchelfUnstable
}:
let
@@ -62,6 +63,7 @@ stdenv.mkDerivation {
nativeBuildInputs = [
autoPatchelfHook
+ patchelfUnstable
];
buildInputs = [
diff --git a/pkgs/development/tools/misc/patchelf/unstable.nix b/pkgs/development/tools/misc/patchelf/unstable.nix
index 7d340cf547b..cd986b539a4 100644
--- a/pkgs/development/tools/misc/patchelf/unstable.nix
+++ b/pkgs/development/tools/misc/patchelf/unstable.nix
@@ -2,13 +2,13 @@
stdenv.mkDerivation rec {
pname = "patchelf";
- version = "unstable-2023-04-25";
+ version = "unstable";
src = fetchFromGitHub {
owner = "NixOS";
repo = "patchelf";
- rev = "008a582741617e2d7d5aa4aab1e8ddfdec0067d9";
- sha256 = "sha256-SC9zZbHN1p5BD6YHr+/ZNelmmZDozEO/vDwuCdJJCcs=";
+ rev = "ac212d0e6fb8b741e5a5e9ea61091149103f401c";
+ sha256 = "sha256-JtobCiZEl3KeXT5CAhXTRhjAPgTVx2upVAUTJNCb/a0=";
};
# Drop test that fails on musl (?)... yields a binary/library that at least can be loaded - I mean, some symbols in Edit: also, in all the invalid cases ... where the fourth, uhm, part (segment? not sure on the terminology) has an offset of zero; I don't know much about elf files or how the stuff gets mapped into RAM, but it feels sus. For comparison, here's a correct Edit 2: here's a patchelf's log when building an invalid The |
|
i think i'm seeing the same, or very similar, on a recent guix (i.e. patchelf i'm downloading the go-ethereum binary release and patching it to run on guix using patchelf (package source is available here). if i read the git log correctly, then what broke it for me was a patchelf update from the moving parts are:
|
|
a nonguix issue that is probably related: https://gitlab.com/nonguix/nonguix/-/issues/350
|
|
@attila-lendvai could you try using #544? |
sadly, i do not notice any difference. it looks like it produces the same output with my binary. but i've set up myself to relatively easily experiment with various different patchelf versions, so let me know if i should try anything else! |
|
someone at @nonguix identified v0.16.1 as the latest that still works. i tried go-ethereum with that version, and i can confirm that it works with v0.16.1. |
On current
staging-nextiteration quite a few emacs-dependent packages are failing. The failures seem to stem from the fact thatemacsis incorrectly modified bypatchelf-0.17.2(0.15.0works, bisected innixpkgsby @mweinelt).It seems to have something to do with modified library list:
If
gdbis to be believed loadable program headers that contain".dynstr"and".dynamic"are not what they should be.LD_DEBUGalso suggests very little could be loaded byld.so:eu-elflintis also unhappy:The text was updated successfully, but these errors were encountered: