Crash when running mmm scan

[yesrod]

What happened?

After running ./mmm scan, the application crashed. I also ran the scan with the --debug flag, but no additional output was generated.

# ./mmm scan
terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc
Aborted (core dumped)

What did you expect to happen?

I expected it to scan for existing mods and do something with that information.

Which command did you run?

mmm scan

Operating System

Linux

What version of MMM are you running?

2.0.6

Contents of the modlist.json

{
  "loader": "paper",
  "gameVersion": "1.21.3",
  "defaultAllowedReleaseTypes": [
    "release"
  ],
  "modsFolder": "./plugins",
  "mods": []
}

Contents of the modlist-lock.json

[]

I have updated

• I swear I have tried it with the latest version!

[meza]

This is very odd! Can you try downloading a previous version maybe?
Also I assume mmm worked with other commands before, right?

[yesrod]

This is very odd! Can you try downloading a previous version maybe?

Sure, I'll try older versions and see what happens.

Also I assume mmm worked with other commands before, right?

Yes, mmm init worked, as well as mmm add.

[yesrod]

Apologies for the delay, this fell off my todo list.

I tried version 2.0.0 today, it exhibits the same behavior. I also tried every possible combination of the -d/--debug argument, with the same result.

$ ./mmm-2.0.0 scan
terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc
Aborted (core dumped)
$ ./mmm-2.0.0 scan -d
terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc
Aborted (core dumped)
$ ./mmm-2.0.0 -d scan
terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc
Aborted (core dumped)
$ ./mmm-2.0.0 scan --debug
terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc
Aborted (core dumped)
$ ./mmm-2.0.0 --debug scan
terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc
Aborted (core dumped)

I'll keep going back in time until I find a version that works, or run out of versions.

[yesrod]

Unfortunately 2.0.0 is the earliest version that supports Paper, so I didn't test any other versions.

I ran mmm with strace and found what it's doing. It's scanning the plugins directory, finding a directory called .paper-remapped, and promptly trying to allocate a massive amount of memory. The tail end of the strace output follows:

openat(AT_FDCWD, "/media/pterodactyl/volumes/901c6d56-d70d-4d2b-9555-2ff9d339ee22/config", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 28
fstat(28, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
getdents64(28, 0x4dd28e0 /* 5 entries */, 32768) = 176
getdents64(28, 0x4dd28e0 /* 0 entries */, 32768) = 0
close(28)                               = 0
openat(AT_FDCWD, "/media/pterodactyl/volumes/901c6d56-d70d-4d2b-9555-2ff9d339ee22/config/legacy-backup", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 28
fstat(28, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
getdents64(28, 0x4dd28e0 /* 3 entries */, 32768) = 88
getdents64(28, 0x4dd28e0 /* 0 entries */, 32768) = 0
close(28)                               = 0
openat(AT_FDCWD, "/media/pterodactyl/volumes/901c6d56-d70d-4d2b-9555-2ff9d339ee22/cache", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 28
fstat(28, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
getdents64(28, 0x4dd28e0 /* 16 entries */, 32768) = 608
getdents64(28, 0x4dd28e0 /* 0 entries */, 32768) = 0
close(28)                               = 0
openat(AT_FDCWD, "/media/pterodactyl/volumes/901c6d56-d70d-4d2b-9555-2ff9d339ee22/plugins/.paper-remapped", O_RDONLY) = 28
fstat(28, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
fstat(28, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lseek(28, 0, SEEK_END)                  = 9223372036854775807
lseek(28, 0, SEEK_SET)                  = 0
mmap(NULL, 9223372036854779904, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory)
brk(0x8000000004f27000)                 = 0x7102000
mmap(NULL, 9223372036854910976, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory)
mmap(NULL, 134217728, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x72f1f8000000
munmap(0x72f1fc000000, 67108864)        = 0
mprotect(0x72f1f8000000, 135168, PROT_READ|PROT_WRITE) = 0
mmap(NULL, 9223372036854779904, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory)
futex(0x72f245d22230, FUTEX_WAKE_PRIVATE, 2147483647) = 0
write(2, "terminate called after throwing "..., 48terminate called after throwing an instance of ') = 48
write(2, "std::bad_alloc", 14std::bad_alloc)          = 14
write(2, "'\n", 2'
)                      = 2
write(2, "  what():  ", 11  what():  )             = 11
write(2, "std::bad_alloc", 14std::bad_alloc)          = 14
write(2, "\n", 1
)                       = 1
rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0
gettid()                                = 1462938
getpid()                                = 1462938
tgkill(1462938, 1462938, SIGABRT)       = 0
--- SIGABRT {si_signo=SIGABRT, si_code=SI_TKILL, si_pid=1462938, si_uid=999} ---
+++ killed by SIGABRT (core dumped) +++
Aborted (core dumped)

I'll see if that directory is important, and if not I'll remove it and try again.

EDIT: It's not specific to the .paper-remapped directory; if I remove that directory it promptly chokes on a different one.

[meza]

Yeah, seems like scan is a problem child! We've also got #767 going on.
The current workaround is to add mods by hand with the add command if it's not a huge problem. Or scan in chunks.
It's most likely a mod that isn't on either Curseforge or Modrinth and if that's not in the directory it would work.

I am rewriting the whole thing in golang and it should make all of these go away but it's a bit of ways away.

Until then I'm trying to hunt it down so the more information/examples/conflicting mods/files we can find, the better!

[meza]

Closing in hopes of 2.0.7 fixing it. Please reopen if not