Closed modscleo4 closed 2 years ago
Are you able to give me a stack trace for the assertion?
I think it was something like this: /usr/include/c++/11.1.0/bits/stl_vector.h:1045: std::vector<_Tp, _Alloc>::reference std::vector<_Tp, _Alloc>::operator[](std::vector<_Tp, _Alloc>::size_type) [with _Tp = long unsigned int; _Alloc = std::allocator<long unsigned int>; std::vector<_Tp, _Alloc>::reference = long unsigned int&; std::vector<_Tp, _Alloc>::size_type = long unsigned int]: Assertion '__n < this->size()' failed.
I ran ntfs2btrfs with GDB but it stopped at libc
Thanks, that helps - it looks like you've defined _GLIBCXX_DEBUG
while I didn't. Does https://github.com/maharmstone/ntfs2btrfs/commit/527e13b14a5c18da92245dac3338515b15486232 fix your problem?
Sorry, i've been too busy
I will try to reproduce the bug as soon as possible and give you a reply
I am using the latest version on the AUR it this path didn't fix the issue
I just got the same error.
Processing inode 2245846 / 2245846 (100.0%)
Mapped 1755901 inodes directly.
Rewrote 1 inodes.
Inlined 260211 inodes.
Updating directory sizes
Calculating checksums 430285926 / 430285926 (100.0%)
/usr/include/c++/11.2.0/bits/stl_vector.h:1045: std::vector<_Tp, _Alloc>::reference std::vector<_Tp, _Alloc>::operator[](std::vector<_Tp, _Alloc>::size_type) [with _Tp = unsigned char; _Alloc = default_init_allocator<unsigned char>; std::vector<_Tp, _Alloc>::reference = unsigned char&; std::vector<_Tp, _Alloc>::size_type = long unsigned int]: Assertion '__n < this->size()' failed.
fish: Job 1, 'sudo ntfs2btrfs /dev/sdc1' terminated by signal SIGABRT (Abort)
At this point, is my data likely to still be intact?
At this point, is my data likely to still be intact?
Yes, no data was lost.
I'll try to run ntfs2btrfs again, I had to format my drive and lost everything, but I'll try to reproduce this bug and generate a core dump
If you can let me know which line of the code is generating the assertion, I'll have a look.
Hi,
Same issue for me :
Using Zstd compression.
Using CRC32C for checksums.
Not calculating checksums.
Processing inode 7735 / 7735 (100.0%)
Mapped 7199 inodes directly.
Rewrote 0 inodes.
Inlined 35 inodes.
Updating directory sizes
/usr/include/c++/11.2.0/bits/stl_vector.h:1045: std::vector<_Tp, _Alloc>::reference std::vector<_Tp, _Alloc>::operator[](std::vector<_Tp, _Alloc>::size_type) [with _Tp = unsigned char; _Alloc = default_init_allocator<unsigned char>; std::vector<_Tp, _Alloc>::reference = unsigned char&; std::vector<_Tp, _Alloc>::size_type = long unsigned int]: Assertion '__n < this->size()' failed.
Abandon
Again, I'll need to know which line of code is causing this in order to be able to fix it.
(gdb) r /dev/sda4
Starting program: /usr/bin/ntfs2btrfs /dev/sda4
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
Using Zstd compression.
Using CRC32C for checksums.
Processing inode 235629 / 235629 (100.0%)
Mapped 139696 inodes directly.
Rewrote 33 inodes.
Inlined 42220 inodes.
Updating directory sizes
Calculating checksums 6794819 / 6794819 (100.0%)
/usr/include/c++/11.2.0/bits/stl_vector.h:1045: std::vector<_Tp, _Alloc>::reference std::vector<_Tp, _Alloc>::operator[](std::vector<_Tp, _Alloc>::size_type) [with _Tp = unsigned char; _Alloc = default_init_allocator<unsigned char>; std::vector<_Tp, _Alloc>::reference = unsigned char&; std::vector<_Tp, _Alloc>::size_type = long unsigned int]: Assertion '__n < this->size()' failed.
Program received signal SIGABRT, Aborted.
0x00007ffff7ade34c in __pthread_kill_implementation () from /usr/lib/libc.so.6
(gdb) bt
#0 0x00007ffff7ade34c in __pthread_kill_implementation () from /usr/lib/libc.so.6
#1 0x00007ffff7a914b8 in raise () from /usr/lib/libc.so.6
#2 0x00007ffff7a7b534 in abort () from /usr/lib/libc.so.6
#3 0x0000555555578c6a in ?? ()
#4 0x00007fffffffe110 in ?? ()
#5 0x0000555555565c15 in ?? ()
#6 0x00007fffffffe110 in ?? ()
#7 0x000055555556a3af in ?? ()
#8 0x000000007e812a30 in ?? ()
#9 0x00005555555e8dc0 in ?? ()
#10 0x00007fffffffe0f0 in ?? ()
#11 0x00007fff00000003 in ?? ()
#12 0x00007fffffffe110 in ?? ()
#13 0x00005555555e9010 in ?? ()
#14 0x0000000000000000 in ?? ()
(gdb) info registers
rax 0x0 0
rbx 0x7ffff7962740 140737347200832
rcx 0x7ffff7ade34c 140737348756300
rdx 0x6 6
rsi 0x470e4 291044
rdi 0x470e4 291044
rbp 0x470e4 0x470e4
rsp 0x7fffffffde80 0x7fffffffde80
r8 0x7fffffffdf50 140737488346960
r9 0x0 0
r10 0x8 8
r11 0x246 582
r12 0x6 6
r13 0x0 0
r14 0x1000 4096
r15 0x7fffffffe490 140737488348304
rip 0x7ffff7ade34c 0x7ffff7ade34c <__pthread_kill_implementation+284>
eflags 0x246 [ PF ZF IF ]
cs 0x33 51
ss 0x2b 43
ds 0x0 0
es 0x0 0
fs 0x0 0
gs 0x0 0
No line number information available for address 0x7ffff7ade34c <__pthread_kill_implementation+284>
Is there any way I can help?
Is there any way I can help?
@nkrichronos What is your ntfs2btrfs
version?
ntfs2btrfs --version
returns
ntfs2btrfs 20210923
I installed it with the ntfs2btrfs-git AUR package.
Would it be possible for you to compile this yourself, and give me a full backtrace?
Just compiled, working on the backtrace.
Aaaaaand that worked :P
I think you did actually fix it with commit 527e13b
I wonder why ntfs2btrfs-git is not updated to the latest commit, is the PKGBUILD working as intended?
Aaaaaand that worked :P
I think you did actually fix it with commit 527e13b
That's nice to know. I tried to run before on Visual Studio debugger so I can see the line it fails but it ran without throwing that exception. I'll go back before [527e13b] to see if that commit really fixed, but apparently yes.
I wonder why ntfs2btrfs-git is not updated to the latest commit, is the PKGBUILD working as intended?
I thought the PKGBUILD was setting an specific commit but no, maybe something with pkgver=r220.7664363
I wonder why ntfs2btrfs-git is not updated to the latest commit, is the PKGBUILD working as intended?
I thought the PKGBUILD was setting an specific commit but no, maybe something with
pkgver=r220.7664363
the pkgver is updated after a git clone is ran, so probably not that (unless its not a well made PKGBUILD)
Do we know what compiler flags the repo maintainers are using?
Do we know what compiler flags the repo maintainers are using?
This is the PKGBUILD, the only flag is -DCMAKE_INSTALL_PREFIX
https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=ntfs2btrfs-git
I finally made it crash, this is the line:
dev.read(&ret[buf_start], buf_end - buf_start);
[527e13b] really fixed this bug, so I'm closing this issue
There is a bug between commit 7f32753bca64b66a168d1759313c02d7bf87516a and bfb5124053a4cdbf6137a9d411123772b1113d74 causing ntfs2btrfs failing at approx. 32% inodes processed (both Windows and Linux)