Hacking WiiFlow Lite

  • Thread starter Thread starter fledge68
  • Start date Start date
  • Views Views 1,040,022
  • Replies Replies 4,838
  • Likes Likes 66
@kaisersozeh Use the values in the code dump section of the DSI screen. Run gdb by typing "gdb boot.elf" then you can use the "info line" command to see where the address listed on the exception screen. (e.g.: "info line *0x80008422")

It's a stack so the addresses should give you earlier locations in the source as you go down the list.
 
@kaisersozeh Use the values in the code dump section of the DSI screen. Run gdb by typing "gdb boot.elf" then you can use the "info line" command to see where the address listed on the exception screen. (e.g.: "info line *0x80008422")

It's a stack so the addresses should give you earlier locations in the source as you go down the list.
i get this message
the term 'gdb' is not recognized as a cmdlet, function, or script blah blah blah

so any idea whats wrong?
 
As long as you have the matching elf for the dol you're running you can use gdb by itself to determine where the crash happened if it generates a DSI exception.
Whoa that is super cool! I'm assuming a DSI exception is when I get a full black screen full of memory addresses which I presume is a stack trace or similar? I'll do some more research on that!

Edit: nevermind just saw your other comment (didn't realize there was a new page when I replied). Awesome, so glad there's a straightforward way to do debug these crashes.

I saw something about that on wiibrew. Ill try later today. As for gdb did i miss installing something or do i have to set a path to gdb? I thought it was built into devkitpro.
It should be in devkitPPC. In my installation (on macOS), it's in /opt/devkitpro/devkitPPC/bin and is called powerpc-eabi-gdb

kaisersozeh said:
Sorry, by what mechanism can you do this - GDB (something database?) against a reference in a DSI exception?
Where's the reference in the DSI display (or is it the whole thing), what is GDB?
@kaisersozeh to give you a clear answer, GDB is GNU Debugger. It's part of the GCC (GNU Compiler) package of tools. Debuggers let you inspect and manipulate memory, set breakpoints to stop at certain parts of the code, etc. However, when running on a separate machine, things get more tricky.
 
Last edited by einsteinx2,
ok i did not have gdb, powerpc-eabi-gdb, or eabi-powerpc-addr2line.

i downloaded and installed insight for devkitpro. not sure if it matters where i installed it. inside the bin foler is powerpc-eabi-gdb.exe
and now gdb seems to be working. it loads up and says reading symbols from the boot.elf

but when i type info line *0x8087f054
it says no line number info available for that address and the others

i wanna scream!!!!!!!
am i doing something wrong?
 
Have you tried powerpc-eabi-addr2line -e boot.elf? I've used it several times to debug stuff.
But gdb might better in this case, I don't know...
 
@Wiimpathy THANKS!

i found powerpc-eabi-addr2line.exe its in c:\devkitpro\devkitppc\bin
i dont remember it being there. maybe after i installed insight.

i'm trying it now and it seems to be working. thanks again!

edit: well that didn't seem to help. i see nothing wrong with the lines of code i got and the first one is where i figured it had stopped. here's what i got:

8075c958
C:/sources/wfl_source/source/menu/menu_main.cpp:302
8075b400 --> 8075c958
C:/sources/wfl_source/source/menu/menu_main.cpp:66
8073a2cc -->8075b400 --> 8075c958
C:/sources/wfl_source/source/menu/menu.cpp:2223
80730854 --> 8073a2cc -->8075b400 --> 8075c958
C:/sources/wfl_source/source/menu/menu.cpp:2269 (discriminator 6)
80717724 --> 80730854 --> 8073a2cc -->8075b400 --> 8075c958
C:/sources/wfl_source/source/list/ListGenerator.cpp:290
80716424 --> 80717724 --> 80730854 --> 8073a2cc -->8075b400 --> 8075c958
C:/sources/wfl_source/source/list/ListGenerator.cpp:52
806ff308 --> 80716424 --> 80717724 --> 80730854 --> 8073a2cc -->8075b400 --> 8075c958
C:/sources/wfl_source/source/gui/GameTDB.cpp:79
80872968 --> 806ff308 --> 80716424 --> 80717724 --> 80730854 --> 8073a2cc -->8075b400 --> 8075c958
??:?
8087f054 --> 80872968 --> 806ff308 --> 80716424 --> 80717724 --> 80730854 --> 8073a2cc -->8075b400 --> 8075c958
??:?
??:0

i have no idea what the ??:? means or what discrimator 6 means?
so im assuming the menu_main.cpp:302 is where it stopped or the function that caused the crash?
 
Last edited by fledge68,
The binaries are in "/devkitPro/devkitPPC/powerpc-eabi/bin".

The elf file has to be the same build as the dol that generated the exception in order for it to find the proper source location.

Sorry, I was away for a few days to go to my sister's memorial. :(
 
Last edited by GreyWolf,
  • Like
Reactions: fledge68
The binaries are in "/devkitPro/devkitPPC/powerpc-eabi/bin".

The elf file has to be the same build as the dol that generated the exception in order for it to find the proper source location.

Sorry, I was away for a few days to go to my sister's memorial. :(
Yes i found powerpc-eabi-gdb there as well. But the memory addresses didnt give me anything. With wiimpathys method above they showed up as ??. When i returned to coverflow it didnt crash right away but the box mesh for the covers on screen was messed up with a weird white triangle coming off the side of each cover. Oh well.
 
Yes i found powerpc-eabi-gdb there as well. But the memory addresses didnt give me anything. With wiimpathys method above they showed up as ??. When i returned to coverflow it didnt crash right away but the box mesh for the covers on screen was messed up with a weird white triangle coming off the side of each cover. Oh well.

Is it the revision 1138 that's currently in the repository? I'll see if I can reproduce it as well.
 
Is it the revision 1138 that's currently in the repository? I'll see if I can reproduce it as well.
Yes it is. What i did was delete 3 wii pngs and there matching wfc files and the did ddownload missing covers and it downloaded the covers but upon going back to main screen the cover shapes were messed up and then it crashed.
 
Ok, I got it compiled and set up. On first attempt to download covers I got a DSI exception about 15-20 seconds in to the process. I just tried it a second time and it went through about 5 covers and crashed again. Same stack trace, too.

Here's a copy of the gdb session for stack trace. It shows which line each address refers to and which file it's in.
Code:
GNU gdb (GDB) 7.11
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=i686-w64-mingw32 --target=powerpc-eabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from boot.elf...done.
(gdb) info line *0x8087b228
No line number information available for address 0x8087b228 <memset+120>
(gdb) info line *0x80714038
Line 151 of "D:/Source/wiiflow_lite/source/gui/FreeTypeGX.cpp"
   starts at address 0x80714038 <FreeTypeGX::loadGlyphData(FT_Bitmap_*, ftgxCharData_*)+68>
   and ends at 0x80714040 <FreeTypeGX::loadGlyphData(FT_Bitmap_*, ftgxCharData_*)+76>.
(gdb) info line *0x80712440
Line 319 of "D:/Source/wiiflow_lite/source/gui/text.cpp"
   starts at address 0x80712434 <CText::setFrame(float, unsigned short, bool, bool)+312>
   and ends at 0x80712448 <CText::setFrame(float, unsigned short, bool, bool)+332>.
(gdb) info line *0x8071c760
Line 1658 of "D:/Source/wiiflow_lite/source/menu/menu_game.cpp"
   starts at address 0x8071c758 <CMenu::_launchGame(dir_discHdr*, bool, bool)+380>
   and ends at 0x8071c790 <CMenu::_launchGame(dir_discHdr*, bool, bool)+436>.
(gdb) info line *0x80725900
Line 558 of "c:\devkitpro\devkitppc\powerpc-eabi\include\c++\6.3.0\bits/basic_string.h"
   starts at address 0x80725900 <CMenu::_config1()+448> and ends at 0x80725908 <CMenu::_config1()+456>.
(gdb) info line *0x80725c18
Line 96 of "D:/Source/wiiflow_lite/source/menu/menu_config.cpp" starts at address 0x80725c18 <CMenu::_config(int)+96>
   and ends at 0x80725c20 <CMenu::_config(int)+104>.
(gdb) info line *0x8075cd40
Line 387 of "D:/Source/wiiflow_lite/source/menu/menu_main.cpp" starts at address 0x8075cd40 <CMenu::main()+2980>
   and ends at 0x8075cd60 <CMenu::main()+3012>.
(gdb) info line *0x806e8dc0
Line 109 of "D:/Source/wiiflow_lite/source/main.cpp" starts at address 0x806e8db8 <main(int, char**)+512>
   and ends at 0x806e8dc4 <main(int, char**)+524>.
(gdb) info line *0x806e8acc
No line number information available for address 0x806e8acc <__crtmain+60>
(gdb)

Being that the top of the stack is a memset() call I suspect it's OOM. It looks like it's failing to get memory for a text object. I'm not sure why the reference to CMenu::_launchGame() is on the stack as it was in the "download all" dialog when it crashed, not in game launch mode.

There seems to be a weird visual artifacting issue in the default background gradient near the top of the main screen around the title name text but I'm not sure if that's relevant.

I have 58 GC games and 168 Wii games on a physical external drive (total of 226).
 
  • Like
Reactions: einsteinx2
Ok, I got it compiled and set up. On first attempt to download covers I got a DSI exception about 15-20 seconds in to the process. I just tried it a second time and it went through about 5 covers and crashed again. Same stack trace, too.

Here's a copy of the gdb session for stack trace. It shows which line each address refers to and which file it's in.
Code:
GNU gdb (GDB) 7.11
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=i686-w64-mingw32 --target=powerpc-eabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from boot.elf...done.
(gdb) info line *0x8087b228
No line number information available for address 0x8087b228 <memset+120>
(gdb) info line *0x80714038
Line 151 of "D:/Source/wiiflow_lite/source/gui/FreeTypeGX.cpp"
   starts at address 0x80714038 <FreeTypeGX::loadGlyphData(FT_Bitmap_*, ftgxCharData_*)+68>
   and ends at 0x80714040 <FreeTypeGX::loadGlyphData(FT_Bitmap_*, ftgxCharData_*)+76>.
(gdb) info line *0x80712440
Line 319 of "D:/Source/wiiflow_lite/source/gui/text.cpp"
   starts at address 0x80712434 <CText::setFrame(float, unsigned short, bool, bool)+312>
   and ends at 0x80712448 <CText::setFrame(float, unsigned short, bool, bool)+332>.
(gdb) info line *0x8071c760
Line 1658 of "D:/Source/wiiflow_lite/source/menu/menu_game.cpp"
   starts at address 0x8071c758 <CMenu::_launchGame(dir_discHdr*, bool, bool)+380>
   and ends at 0x8071c790 <CMenu::_launchGame(dir_discHdr*, bool, bool)+436>.
(gdb) info line *0x80725900
Line 558 of "c:\devkitpro\devkitppc\powerpc-eabi\include\c++\6.3.0\bits/basic_string.h"
   starts at address 0x80725900 <CMenu::_config1()+448> and ends at 0x80725908 <CMenu::_config1()+456>.
(gdb) info line *0x80725c18
Line 96 of "D:/Source/wiiflow_lite/source/menu/menu_config.cpp" starts at address 0x80725c18 <CMenu::_config(int)+96>
   and ends at 0x80725c20 <CMenu::_config(int)+104>.
(gdb) info line *0x8075cd40
Line 387 of "D:/Source/wiiflow_lite/source/menu/menu_main.cpp" starts at address 0x8075cd40 <CMenu::main()+2980>
   and ends at 0x8075cd60 <CMenu::main()+3012>.
(gdb) info line *0x806e8dc0
Line 109 of "D:/Source/wiiflow_lite/source/main.cpp" starts at address 0x806e8db8 <main(int, char**)+512>
   and ends at 0x806e8dc4 <main(int, char**)+524>.
(gdb) info line *0x806e8acc
No line number information available for address 0x806e8acc <__crtmain+60>
(gdb)

Being that the top of the stack is a memset() call I suspect it's OOM. It looks like it's failing to get memory for a text object. I'm not sure why the reference to CMenu::_launchGame() is on the stack as it was in the "download all" dialog when it crashed, not in game launch mode.

There seems to be a weird visual artifacting issue in the default background gradient near the top of the main screen around the title name text but I'm not sure if that's relevant.

I have 58 GC games and 168 Wii games on a physical external drive (total of 226).
thanks for testing and the info. when i checked my code dump it only had 3 mem addresses and they all said - No line number information available for address with <strchr> something

i noticed this part of menu_download.cpp
Code:
u32 bufferSize = 0x280000;    // Maximum download size 2 MB
    u8 *buffer = (u8*)MEM2_alloc(bufferSize);
    if(buffer == NULL)
    {
        LWP_MutexLock(m_mutex);
        _setThrdMsg(_t("dlmsg27", L"Not enough memory!"), 1.f);
        LWP_MutexUnlock(m_mutex);
        m_thrdWorking = false;
        return 0;
    }
i noticed that bufferSize is a u32 (unsigned long integer - 4 bytes =32 bits)
but in mem2.cpp
Code:
void *MEM2_alloc(unsigned int s)
{
    return g_mem2gp.Alloc(s);
}
its a unsigned int which is 16 bits 2 bytes and a max value of 64k right? or am i missing something.
 
thanks for testing and the info. when i checked my code dump it only had 3 mem addresses and they all said - No line number information available for address with <strchr> something

i noticed this part of menu_download.cpp
Code:
u32 bufferSize = 0x280000;    // Maximum download size 2 MB
    u8 *buffer = (u8*)MEM2_alloc(bufferSize);
    if(buffer == NULL)
    {
        LWP_MutexLock(m_mutex);
        _setThrdMsg(_t("dlmsg27", L"Not enough memory!"), 1.f);
        LWP_MutexUnlock(m_mutex);
        m_thrdWorking = false;
        return 0;
    }
i noticed that bufferSize is a u32 (unsigned long integer - 4 bytes =32 bits)
but in mem2.cpp
Code:
void *MEM2_alloc(unsigned int s)
{
    return g_mem2gp.Alloc(s);
}
its a unsigned int which is 16 bits 2 bytes and a max value of 64k right? or am i missing something.

Try using the stack dump addresses that are separated with a -> instead of the code section. They are in reverse calling order. (i.e.: the first address on the list is the last address that was executing before the crash) If it was running in a separate thread it might be harder to debug. The dump screen might not differentiate between which thread the code is in.

I thought int was 32-bit on devkitPPC but I could be wrong. You could always output "sizeof(unsigned int)" to a log file or console screen.
 
I tried enabling logging and memory reporting but it's not particularly helpful.
Welcome to WiiFlow Lite 4.4.0 (r1139)!
This is the debug output.
Real Wii
WiiFlow is in real nand mode
IOS58 v6176
patched isfs_permissions 1 times.
patched es_setuid 1 times.
patched es_identify 1 times.
patched hash_check 0 times.
patched new_hash_check 1 times.
Init ISFS
Found WiiFlow Save
FAT Partition at sd: mounted.
Changing USB port to port 0....
* * * * * * * * * * * *
* HDD Information
* Sectors: 1953521071
* Size [Sector Size]: 931 GB [512]
* * * * * * * * * * * *
FAT Partition at usb1: mounted.
SHND: Running sound thread
Wiiflow boot.dol Location: sd:/apps/wiiflow_lite
Data Directory: sd:/wiiflow
Wii Games Directory: %s:/wbfs
Nintendont found
GameCube Games Directory: %s:/games
Loading cIOS map
Found d2x base 37 in slot 245
Found d2x base 38 in slot 246
Found d2x base 53 in slot 247
Found d2x base 55 in slot 248
Found d2x base 56 in slot 249
Found d2x base 57 in slot 250
Found d2x base 58 in slot 251
Emu NAND Full Path = sd:/nands/default
IOS Compatible NAND Path = /nands/default
Creating Gamelist
Games found: 58
Coverflow started!
start wiiflow main screen
Mem1 Free: 10403824
Mem2 Free: 22665856
Mem2 Free: 22667008
Coverflow stopped!
Creating Gamelist
Games found: 5
Coverflow started!
Mem1 Free: 10379248
Mem2 Free: 22697088
Coverflow stopped!
Creating Gamelist
Games found: 0
Mem2 Free: 22705536
Creating Gamelist
Games found: 169
Coverflow started!
Mem1 Free: 10358768
Mem2 Free: 22556032
Mem2 Free: 22556160
Mem2 Free: 22554880
Mem2 Free: 22554240
 
I don't know if it's the good place to post but I think it could be useful.

CreateCache 0.1

Source code

It scans all your Wiiflow boxcovers and generate the cache files. Only plugins covers are converted, Wii covers are skipped.
If a .wfc file already exists, it won't be overwritten. If you have a lot of covers(thousands), the conversion takes hours.
You can check the log file called log_cachecreate.txt for any error.
Jpeg files are not supported! Cache compress neither, only compress texture.

What are the advantages :
- For large collection, you don't have to browse all the covers per plugin. It's doing all the process at once without any interaction.
- It should be a bit faster, there's no gui, it should essentially use mem1(well I think?).
- It will warn you if there are errors in a log file. For example, I had covers that were larger than 1090, so it couldn't create the cache.

It's not 100% guaranted but it should work rather well. I've made a usb test with about 10000 covers, and that took about 4 hours.
 
I don't know if it's the good place to post but I think it could be useful.

CreateCache 0.1

Source code

It scans all your Wiiflow boxcovers and generate the cache files. Only plugins covers are converted, Wii covers are skipped.
If a .wfc file already exists, it won't be overwritten. If you have a lot of covers(thousands), the conversion takes hours.
You can check the log file called log_cachecreate.txt for any error.
Jpeg files are not supported! Cache compress neither, only compress texture.

What are the advantages :
- For large collection, you don't have to browse all the covers per plugin. It's doing all the process at once without any interaction.
- It should be a bit faster, there's no gui, it should essentially use mem1(well I think?).
- It will warn you if there are errors in a log file. For example, I had covers that were larger than 1090, so it couldn't create the cache.

It's not 100% guaranted but it should work rather well. I've made a usb test with about 10000 covers, and that took about 4 hours.
Awesome work!

Do you have or want to create a GitHub repo for it to make contributions easier?

I'd love to help with this when I have time (if that ever happens haha). Having automatic cache creation as both an option in WiiFlow for Wii, GC, and plugins as well as potentially a desktop version would be awesome.
 
  • Like
Reactions: kaisersozeh
Ok, since all my previous wii homebrews archives are now falsely flagged as virus by this damn firefox, I decided to migrate to gihub.

Here's the source : https://github.com/Wiimpathy/CreateCache

I'm not very familiar with Github but any help are welcome with the source or the documentation. You're right, Wii/GC cache could also be useful. I gave up the desktop version but that'd be very cool indeed.

About the Wiiflow crash when downloading covers, it seems to only be affected when compiling with the windows devkit.(!) When I compile with devkitPPC_r29-1-x86_64 and the same libogc, it doesn't happen.
 

Site & Scene News

Popular threads in this forum