Assertion failure, node->inode != RM_NO_INODE. Lastest develop branch compiled on Raspberry pi 4 #549
Comments
|
Using information from:
This is the run with the recompiled rmlint, using the same command on the same directories and files: ASAN: head of the compile "log": |
|
ASAN generates its own reports so gdb isn't necessary. Seems like part of rmlint may have been built without ASAN. Try a clean rebuild with those flags: If you get the same error you can work around the issue with |
|
Investigating... Just FYI, from the compiles (not just with the sanitise flags): Not sure if the rm_dedupe_main - reflink.c - lchmod warning is important. Raspberry pi does not have libasan at the location you mentioned. I found it at /usr/lib/gcc/arm-linux-gnueabihf/8/libasan.so (assuming this is the correct libasan for gcc 8) (it's the only libasan.so under /usr) Is it OK just to link in the dynamic lib and run as shown below or must I install libasan5 explicitly? This doesn't look like the original error though (?) - I don't see the initial traversal output on screen. |
|
I am able to reproduce the heap-buffer-overflow report with a 32-bit x86 build, but not on x86_64, so I suspect some errors in RM_PLATFORM_32 related code. Will debug further, thanks. |
|
Try patching diff --git a/lib/config.h.in b/lib/config.h.in
index e9a5a3c0..30fda4e2 100644
--- a/lib/config.h.in
+++ b/lib/config.h.in
@@ -57,6 +57,7 @@
#define LLI G_GINT64_FORMAT
+#include <stdint.h> /* for UINTPTR_MAX */
#define RM_PLATFORM_32 (UINTPTR_MAX == 0xffffffff)
#define RM_PLATFORM_64 (UINTPTR_MAX == 0xffffffffffffffff)
|
cebtenzzre
added a commit
to cebtenzzre/rmlint
that referenced
this issue
Jan 24, 2022
The worst of them were an undefined UINTPTR_MAX in RM_PLATFORM_*, which could both be false and caused a stat struct to be mis-casted in traverse.c, and a non-macro HASHER_FADVISE_FLAGS that made rm_hasher_request_readahead a no-op since commit 31cd32f. Also add a static assert in the usual ADD_FILE to make sure it never casts between incompatible stat structs, and -Werror=undef so we don't allow undefined macros to silently evaluate to zero. Fixes sahib#549
cebtenzzre
added a commit
to cebtenzzre/rmlint
that referenced
this issue
Jan 24, 2022
The worst of them were an undefined UINTPTR_MAX in RM_PLATFORM_*, which could both be false and caused a stat struct to be mis-casted in traverse.c, and a non-macro HASHER_FADVISE_FLAGS that made rm_hasher_request_readahead a no-op since commit 31cd32f. Also add a static assert in the usual ADD_FILE to make sure it never casts between incompatible stat structs, and -Werror=undef so we don't allow undefined macros to silently evaluate to zero. The UINTPTR_MAX issue is a regression caused by 90edf02, which removed the inttypes.h include in config.h.in. Fixes sahib#549
Merged
|
I can confirm that the patch fixes the assertion failure on my platform. |
|
Closing. Please re-open if needed. |
cebtenzzre
added a commit
to cebtenzzre/rmlint
that referenced
this issue
Aug 7, 2022
The worst of them were an undefined UINTPTR_MAX in RM_PLATFORM_*, which could both be false and caused a stat struct to be mis-casted in traverse.c, and a non-macro HASHER_FADVISE_FLAGS that made rm_hasher_request_readahead a no-op since commit 31cd32f. Also add a static assert in the usual ADD_FILE to make sure it never casts between incompatible stat structs, and -Werror=undef so we don't allow undefined macros to silently evaluate to zero. The UINTPTR_MAX issue is a regression caused by 90edf02, which removed the inttypes.h include in config.h.in. Fixes sahib#549
Merged
cebtenzzre
added a commit
to cebtenzzre/rmlint
that referenced
this issue
Aug 12, 2022
The worst of them were an undefined UINTPTR_MAX in RM_PLATFORM_*, which caused a stat struct to be mis-casted in traverse.c, and a non-macro HASHER_FADVISE_FLAGS that made rm_hasher_request_readahead a no-op since commit 31cd32f. Also add a static assert to make sure ADD_FILE never casts between incompatible stat structs, and -Werror=undef so we don't allow undefined macros to silently evaluate to zero. The UINTPTR_MAX issue is a regression caused by 90edf02, which removed the inttypes.h include from config.h.in. Fixes sahib#549
cebtenzzre
added a commit
to cebtenzzre/rmlint
that referenced
this issue
Sep 18, 2022
The worst of them were an undefined UINTPTR_MAX in RM_PLATFORM_*, which could both be false and caused a stat struct to be mis-casted in traverse.c, and a non-macro HASHER_FADVISE_FLAGS that made rm_hasher_request_readahead a no-op since commit 31cd32f. Also add a static assert in the usual ADD_FILE to make sure it never casts between incompatible stat structs, and -Werror=undef so we don't allow undefined macros to silently evaluate to zero. The UINTPTR_MAX issue is a regression caused by 90edf02, which removed the inttypes.h include in config.h.in. Fixes sahib#549
cebtenzzre
added a commit
that referenced
this issue
Jun 20, 2023
The worst of them were an undefined UINTPTR_MAX in RM_PLATFORM_*, which caused a stat struct to be mis-casted in traverse.c, and a non-macro HASHER_FADVISE_FLAGS that made rm_hasher_request_readahead a no-op since commit 31cd32f "bugfix: hopefully fix very seldom `g_mutex_clear assert` by waiting for all buffers to return". Also add static assertions to make sure ADD_FILE never casts between incompatible stat structs, and -Werror=undef so we don't allow undefined macros to silently evaluate to zero. The UINTPTR_MAX issue is a regression caused by 90edf02 "includes: de-lint a couple of hundred #includes", which removed the inttypes.h include from config.h.in. Fixes #549
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Version: latest develop branch, --version shows 2.10.1
Platform - Raspberry pi 4 with 4GB RAM
I went back and recompiled 2.10.1 master to check and it compiles and runs without error with this same command, same directories, same files.
Note: This is a placeholder for the failure and investigation.
Hopefully I will have more time next week to recompile and run as advised here: #547 (comment)
The text was updated successfully, but these errors were encountered: