Project

General

Profile

Actions

Emulator Issues #12716

closed

Error when running simple Hello World program with printf call

Added by turbolent about 3 years ago. Updated about 3 years ago.

Status:
Fixed
Priority:
Normal
Assignee:
-
% Done:

0%

Operating system:
N/A
Issue type:
Bug
Milestone:
Current
Regression:
Yes
Relates to usability:
No
Relates to performance:
No
Easy:
No
Relates to maintainability:
No
Regression start:
5.0-10956
Fixed in:
5.0-15419

Description

What's the problem? Describe what went wrong.

When compiling a simple Hello World program that contains a printf call with devkitPro/devkitPPC, and executing the resulting ELF/DOL in Dolphin by using -b -e, it reports an error:

#include <stdio.h>

int main(int argc, char **argv) {
  printf("Hello, world!\n");
}

IntCPU: Unknown instruction 00000000 at PC = 80001800  last_PC = 00000000  LR = 80007208

It looks like the error is reported after the print call was intercepted and completed:

59:21:014 Core/HLE/HLE_OS.cpp:85 N[OSREPORT]: 800057cc->800057c0| Hello, world!

What steps will reproduce the problem?

Run a program with a printf call, see example above.

Is the issue present in the latest development version? For future reference, please also write down the version number of the latest development version.

Yes, in 5.0-15377.

Is the issue present in the latest stable version?

No, 5.0 works.

If the issue isn't present in the latest stable version, which is the first broken version?

5.0-10956, i.e. https://github.com/dolphin-emu/dolphin/pull/8370 broke it.

What are your PC specifications? (CPU, GPU, Operating System, more)

  • OS: macOS 10.15.7
  • CPU: 2.9 GHz 6-Core Intel Core i9
  • GPUs: Intel UHD Graphics 630, Radeon Pro 560X

Is there anything else that can help developers narrow down the issue? (e.g. logs, screenshots,
configuration files, savefiles, savestates)

Screenshot of the error


Files

Screen Shot 2021-10-24 at 11.00.42 AM.png (378 KB) Screen Shot 2021-10-24 at 11.00.42 AM.png Screenshot of the error turbolent, 10/24/2021 09:02 AM
test.dol (131 KB) test.dol Hello world program with printf, DOL format turbolent, 10/24/2021 09:02 AM
test.elf (923 KB) test.elf Hello world program with printf, ELF format turbolent, 10/24/2021 09:02 AM
Actions #1

Updated by JosJuice about 3 years ago

  • Milestone set to Current
  • Regression changed from No to Yes
  • Regression start set to 5.0-10956

I get this instead:

Invalid read from 0x00000000, PC = 0x80011650

Then after a few subsequent panic alerts (invalid reads from 0x2, 0x4, 0x6, 0x8, 0xa), it successfully exits to the Wii Menu.

Actions #2

Updated by phire about 3 years ago

  • Status changed from New to Accepted

Can confirm that it crashes on my machine. I got the same Unknown instruction 00000000 at PC = 80001800 last_PC = 00000000 LR = 80007208

What's really weird is that it works fine (for me, at least) under dual-core, which shouldn't even effect things because nothing is happening on the GPU (though I guess libogc might be initialising it?)

Actions #3

Updated by JosJuice about 3 years ago

I get the Unknown instruction behavior after disabling cheats.

Actions #4

Updated by phire about 3 years ago

Oh, right.
I disabled cheats at the exact same time I disabled dual core and just assumed it was disabling dual core that fixed it.

Dual core has no effect. With cheats enabled, I get no crashing or panic alerts. Though it doesn't exit either.

Actions #5

Updated by sepalani about 3 years ago

What do these executables do on a real Wii? I didn't know you could use printf without initialising the screen first.

Actions #6

Updated by turbolent about 3 years ago

sepalani wrote:

What do these executables do on a real Wii? I didn't know you could use printf without initialising the screen first.

The printf call itself is relying on Dolphin's printf-hooking (https://github.com/dolphin-emu/dolphin/blob/a80fcf38ae51d5a1da76c878f89a5bd073de1c72/Source/Core/Core/HLE/HLE.cpp#L47).
I don't think such a program would run on real hardware, but I do not have a real Wii to test at the moment.

I do understand that supporting such a debugging feature is maybe out-of-scope, but I just wanted to point out that it used to work fine and then broke through a fix (I don't fully understand the PR).

Actions #7

Updated by pokechu22 about 3 years ago

Does the same error happen in a program without printf? Something as trivial as this:

int main(int argc, char **argv) { }

I'm pretty sure that such a program would immediately return to its loader (the homebrew channel usually) on console, so if the same problem happens with that then the behavior of printf without setting up libogc's console is unrelated.

Actions #8

Updated by leoetlino about 3 years ago

Does PR 10186 fix the issue?

Actions #9

Updated by JosJuice about 3 years ago

  • Status changed from Accepted to Fixed
  • Fixed in set to 5.0-15419
Actions

Also available in: Atom PDF