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

Question

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

modscleo4 opened this issue 3 years ago · 25 comments

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

Answer 1 · 2021-10-03T23:01:54.000Z

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

Answer 2 · 2021-10-04T14:16:35.000Z

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

Answer 3 · 2021-10-04T17:05:59.000Z

Thanks, that helps - it looks like you've defined _GLIBCXX_DEBUG while I didn't. Does 527e13b fix your problem?

Answer 4 · 2021-10-06T18:17:51.000Z

Sorry, i've been too busy

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

Answer 5 · 2021-12-04T00:23:21.000Z

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

Answer 6 · 2022-02-24T09:00:30.000Z

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?

Answer 7 · 2022-02-24T14:14:59.000Z

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

Answer 8 · 2022-02-24T17:48:02.000Z

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

Answer 9 · 2022-03-04T21:02:58.000Z

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

Answer 10 · 2022-03-05T03:45:18.000Z

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

Answer 11 · 2022-05-05T16:17:17.000Z

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

Answer 12 · 2022-05-05T16:28:44.000Z

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

Answer 13 · 2022-05-05T16:31:17.000Z

Is there any way I can help?

Answer 14 · 2022-05-05T16:31:37.000Z

Is there any way I can help?

@nkrichronos What is your ntfs2btrfs version?

Answer 15 · 2022-05-05T16:40:31.000Z

ntfs2btrfs --version returns
ntfs2btrfs 20210923

I installed it with the ntfs2btrfs-git AUR package.

Answer 16 · 2022-05-05T16:42:49.000Z

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

Answer 17 · 2022-05-05T16:44:55.000Z

Just compiled, working on the backtrace.

Answer 18 · 2022-05-05T16:50:17.000Z

Aaaaaand that worked :P

I think you did actually fix it with commit 527e13b

Answer 19 · 2022-05-05T16:55:22.000Z

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

Answer 20 · 2022-05-05T17:05:07.000Z

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.

Answer 21 · 2022-05-05T17:06:05.000Z

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

Answer 22 · 2022-05-05T22:52:04.000Z

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)

Answer 23 · 2022-05-05T22:54:26.000Z

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

Answer 24 · 2022-05-06T02:16:28.000Z

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

Answer 25 · 2022-05-06T02:48:14.000Z

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