C++ proposition

[Slice]

I think we can move 

REFIT_MENU_SCREEN MainMenu(1, L"Main Menu", L"Automatic boot");

REFIT_MENU_SCREEN AboutMenu(2, L"About", NULL);

REFIT_MENU_SCREEN HelpMenu(3, L"Help", NULL);

into RefitMain local variables. They attached to main menu created here.

[Jief_Machak]

Let me find the bug before moving code.

I made a mbr, but seems not enough to get a legacy entry.

[Jief_Machak]

I made some legacy entries.

I add this at the end ScanVolumeBootcode :

*Bootable = TRUE;
Volume->HasBootCode = TRUE;
Volume->LegacyOS->IconName = L"win";
Volume->LegacyOS->Name = L"Windows";
Volume->LegacyOS->Type = OSTYPE_WIN;
Volume->BootType = BOOTING_BY_PBR;

so I got "fake" legacy entries, and it's still working.

Did you try a recompile from scratch. EDK build system is not great and it happened to me to have some old objects link with new code.

[Jief_Machak]

Anything in your config.plist that trigger the bug ? Could you send it to me ?

[Jief_Machak]

8 hours ago, Slice said:

The problem is

REFIT_ABSTRACT_MENU_ENTRY is not REFIT_MENU_ITEM_ABSTRACT_ENTRY_LOADER required for virtualization.

You can call, for example "getREFIT_MENU_ITEM_ABSTRACT_ENTRY_LOADER()" on any item, regardless of the object you have.

Because method are "virtual", even upcasted to "REFIT_ABSTRACT_MENU_ENTRY", the subclassed method will be call : the furthest down the hierarchy. So, if the item is a "REFIT_ABSTRACT_MENU_ENTRY" or one of its subclass, the method that return this is called. If it's not a "REFIT_ABSTRACT_MENU_ENTRY", the method at the top level will be called. They all return NULL.

 

That's why it wasn't a problem of memory allocated size. For this mechanism to work, some extra memory must be allocated. "new" do it, AllocatePool does not. The result is an uninitialised vtable. vtable is a table of pointer to function. Uninitialised means crash as soon as you call a virtual method.

 

 

[Slice]

49 minutes ago, Jief_Machak said:

Anything in your config.plist that trigger the bug ? Could you send it to me ?

Nothing interesting

There is FreeDOS image that I can boot by legacy Clover.

There is my config.plist.

there is my command line to start QEMU

qemu -L ~/Desktop/QEMU-Clover/QEMU -m 2048 -cpu core2duo -bios bios.bin  -machine q35 -device ahci,id=ahi -drive format=raw,id=hda,file=/Users/sergey/Desktop/QEMU-Clover/QEMU-test2.img -drive format=raw,id=hdc,file=/Users/sergey/Desktop/QEMU-Clover/freedos.img -usb -device usb-mouse,bus=usb-bus.0,port=2 -device usb-kbd,bus=usb-bus.0,port=1 -serial stdio

But main volume is too large to attach here.

 

config.plist.zip

freedos.img.7z

The bug reproduced on three computers since yesterday evening up to now.

[Jief_Machak]

https://wetransfer.com/ ?

[Slice]

This is debug.log ended at MainMenu.run

 

debug.log.zip

[Jief_Machak]

Interesting : I don't have the "=== [ FindStartupDiskVolume ] =============================" section in my log.

[Slice]

9 minutes ago, Jief_Machak said:

https://wetransfer.com/ ?

https://dropmefiles.com/VYQca

There is old version. Replace here Clover with new version.

Oh, this is my compilation

 

CLOVERX64.efi.zip

[Slice]

Clean XCODE8 compilation from initial. Same crash.

Commits before REFIT_MENU_ENTRY worked.

[Jief_Machak]

do you see "All tests are ok"?

[Slice]

15 hours ago, Slice said:

The crash is at

      if (MainEntry.getLEGACY_ENTRY()) {

I am quite sure the crash is here not matter what compilation.

[Jief_Machak]

Try my compilation : 

CloverX64.efi

[Jief_Machak]

Caught something !

[Slice]

17 minutes ago, Jief_Machak said:

Try my compilation : 

CloverX64.efi

Why it is so large? 1.3Mb

[Jief_Machak]

Line 77, there was "PointerImage = NULL;". In fact, that call the XImage ctor "XImage(EG_IMAGE* egImage)" with NULL as parameter. 

That was a crash.

 

The funny thing is, when I exec in my VM, I can't trace the execution and the exception is not raised. I could see in my debugger that "Width = egImage->Width" with egImage==NULL return 0 !!!

 

THat's why it looks like it worked.

There was a typo. Please pull from git.

[Jief_Machak]

Any better. Tell me because I'm very tired and will leave soon if it's ok.

[Slice]

I am sorry for the bad news. Crash at the same place

Starting Clover revision: 5104 (master, commit c6a59f85f) 

 

[Slice]

The crash happen between 8 and 81

    DBG("DMME 8\n");
    BadgeImageL = Entry->getBadgeImage();
    DBG("DMME 81\n");

It will be good to switch to XImage and then find next bugs.

[Jief_Machak]

I think it's best to find that bug to understand why it's working here and not at yours.

Maybe QEMU is more strict, so I'm trying to switch to that.

 

[Jief_Machak]

Ok, qemu is running, can't see the debug log.

Where is that line "BadgeImageL = Entry->getBadgeImage();" ? I don't have it ??

[Slice]

30 minutes ago, Jief_Machak said:

Ok, qemu is running, can't see the debug log.

Where is that line "BadgeImageL = Entry->getBadgeImage();" ? I don't have it ??

I wrote it for debug purpose. Now there is 

  if (Entry->Row == 0) {
    BadgeImage = Entry->getBadgeImage();
  } //else null

in VOID DrawMainMenuEntry(...)

I committed some changes

[Jief_Machak]

Found it. This time it works in the same QEMU as you.

 

So it was a mPointer used without checking if it's NULL.

[Jief_Machak]

I don't understand this check :

  if (Entry->Row == 0) {
    BadgeImage = Entry->getBadgeImage();
  } //else null

I'd say at this time the logic is : if there is a badge image, draw it.

It's when the menu is created that we decide if an entry would have a badge image or not...