Error: Assertion '__n < this->size()' failed.

[modscleo4]

There is a bug between commit 7f32753bca64b66a168d1759313c02d7bf87516a and bfb5124053a4cdbf6137a9d411123772b1113d74 causing ntfs2btrfs failing at approx. 32% inodes processed (both Windows and Linux)

[maharmstone]

Are you able to give me a stack trace for the assertion?

[modscleo4]

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

[maharmstone]

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?

[modscleo4]

Sorry, i've been too busy

I will try to reproduce the bug as soon as possible and give you a reply

[Etaash-mathamsetty]

I am using the latest version on the AUR it this path didn't fix the issue

[judemille]

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?

[modscleo4]

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

[maharmstone]

If you can let me know which line of the code is generating the assertion, I'll have a look.

[liberodark]

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

[maharmstone]

Again, I'll need to know which line of code is causing this in order to be able to fix it.

[code-irisnk]

(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 ?? ()

[code-irisnk]

(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>

[code-irisnk]

Is there any way I can help?

[modscleo4]

Is there any way I can help?

@nkrichronos What is your ntfs2btrfs version?

[code-irisnk]

ntfs2btrfs --version returns ntfs2btrfs 20210923

I installed it with the ntfs2btrfs-git AUR package.

[maharmstone]

Would it be possible for you to compile this yourself, and give me a full backtrace?

[code-irisnk]

Just compiled, working on the backtrace.

[code-irisnk]

Aaaaaand that worked :P

I think you did actually fix it with commit 527e13b

[code-irisnk]

I wonder why ntfs2btrfs-git is not updated to the latest commit, is the PKGBUILD working as intended?

[modscleo4]

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.

[modscleo4]

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

[Etaash-mathamsetty]

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)

[maharmstone]

Do we know what compiler flags the repo maintainers are using?

[modscleo4]

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

[modscleo4]

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