Memory allocation failure

[Tellie]

I downlaoded odin v0.8.1 and extract it, running a program with pe randomrunner.exe and then get a popup with Internal error while loading randomrunner.exe When i use v0.7.1 it runs ok

[Tellie]

Here to download ​ftp://ftp.netlabs.org/pub/qtapps/temp/CLUB2000.zip

[Silvan Scherrer]

which libc do you have installed? if libc064, please make sure there is no other libc on the system

[dmik]

I confirm that CLUB2000.EXE starts fine with 0.7.1 and exits immediately with 0.8.1. No LIBC064 conflicts here.

[dmik]

The problem is that Odin expects that DosAllocMem can allocate memory starting at the base address of the executable image. In case of CLUB2000.EXE, it's 0x400000. However, for GCC applications, DosAllocMem returns addresses starting from 0x2XX0000. Probably, because GCC reserves a lot of memory for its own purpose (e.g. the heap) while VAC uses some different strategy.

[dmik]

One of the ways to solve it would be to rewrite PE/PEC in assembler. A bit rude but would work.

[dmik]

It seems that the problem affects only executables with the IMAGE_FILE_RELOCS_STRIPPED flag set. This flag seems to indicate an executable with the relocation information stripped from it. Such executable may only be loaded to its base address as all offsets will be wrong otherwise and it's impossible to relocate them.

Executables that are not stripped (e.g. WinRar ones) start fine.

[abwillis]

Unfortunately I don't know the kmk build system well enough to have yet figured out where to add it so that I can verify but I would think that if we add -ZHigh-mem that should move the heap high and give the baseaddress room.

[dmik]

No, the high mem setting is not involved here, it behaves exactly the same in both modes. It seems that just loading libc064.dll causes the first free block of free memory to be moved up. According to theseus, the addresses from 0x00530000 to 0x0252FFFF (0x2000 pages) are allocated by libc064.dll which seems to do that from its own DLL_InitTerm (CRT initialization or such), even before the entry point of the executable gets control so there is nothing we can do about that.

So, the only way so far is to rewrite in assembler.

The kmk system is quite straight forward; in order to cause everything to be rebuilt with -Zhigh-mem you should add this to the base template (defined in Config.kmk) by e.g. appending the following line to your LocalConfig.kmk (or by modifying your copy of Config.kmk directly):

TEMPLATE_OdinCxx_LDFLAGS += -Zhigh-mem

[abwillis]

I had found and tried the above but when it didn't help I wasn't sure if it was because it did not work or I had put it in the wrong place. I had thought -Zhigh-mem put the libc heap high too.

[dmik]

The problem is fixed in r21942. I went the combined way (the startup code replacement in ASM and the rest in C). It is even better than in VAC times as almost all the private memory is free at the time when the loader reserves it (since there is no any DLL besides DOSCALL1 loaded at all while VAC used to already load its own runtime). The lack of the C runtime required to implement a bunch of simple functions like strcpy (and borrow a complex one like vsnprintf from the other part of the Odin code).

[dmik]

Did some more cleanup in r21943.

The problem seems to be solved now; PE/PEC work and a few Win32 EXEs I tried (including the previously failing CLUB2000.EXE test case) start well.