Preallocate large continuous memory block for legacy executable

Question

I'm trying to develop J2ME game on Linux using this guide by microgram dev.

1. The j2me emulator from Oracle Wireless Toolkit works totally fine after Linux reboot.
2. I run some other apps like browser, some time elapses.
3. I run j2me emulator from WTK and it freezes

Rarely there are crashes with errors like

java: malloc.c:2617: sysmalloc: Assertion `(old_top == initial_top (av) && old_size == 0) || ((unsigned long) (old_size) >= MINSIZE && prev_inuse (old_top) && ((unsigned long) old_end & (pagesize - 1)) == 0)' failed.

or

malloc(): invalid next size (unsorted)

I think the problem is in poorly ported and poorly compiled *.dll -> *.so emulator libraries (libzayit.so) and RAM fragmentation. How can force this emulator process to run on continuous memory block?

Will it help if I try to run it from inside the Docker? Some virtualization with sandboxed memory mapper may help too.

Also tried

echo 1 | sudo tee /proc/sys/vm/compact_memory

but it didn't help.

Also some java runtime memory settings may help like disabling garbage collector.

More details: I don't experience similar problems with another apps, so it's not hardware problem. Also this problem with this emulator reproduces on another developer Linux machine. Also worth to mention I'm running 32-bit emulator on 64-bit Ubuntu 22.04 system (dependencies were installed like this sudo apt install libxt6:i386).

Update

Forcing to run on single CPU core results in malloc errors:

taskset --cpu-list 1 /home/d9k/soft/j2me/WTK2.5.2/bin/emulator -Xdescriptor:/home/d9k/j2mewtk/2.5.2/apps/Games/bin/Games.jad
malloc(): invalid next size (unsorted)

--cpu-list 3 => corrupted size vs. prev_size

--cpu-list 4 => malloc(): invalid next size (unsorted)

--cpu-list 6 => malloc(): mismatching next->prev_size (unsorted)

Answer 1

How can force this emulator process to run on continuous memory block?

no, that's not how memory allocation works. You can try to replace one malloc implementation with a different one, but the problem here doesn't seem to be the part that handles the memory allocation – the other software seems to write to memory locations it shouldn't, corrupting headers / allocation tables in the process memory.

So, this seems like plain software bugs to me!

You can install the debug headers (or export DEBUGINFOD_URLS= as appropriate for your linux distro), and run your emulator in gdb, i.e., through gdb --args /path/to/executable --argument1 --argument2…, wait for the crash and then use backtrace. If you have systemd-coredumpctl, then you don't even have to do that – you can collect the trace after the crash. coredumpctl list will list previous crashes, coredumpctl debug will open the debugger on the last one.