syscheck crashes on 14.2

[GoogleCodeExporter]

What IOS did you use?
IOS 236 (IOS 36 with patches)

What is the first 4 digits of your Wii's Serial Number?
Before LU64...

What steps will reproduce the problem?
1. Running sysCheck crashed after hitting A to continue scanning.

What is the expected output? What do you see instead?
It did not continue to scan the remainder of IOS.

Please provide any additional information below.
Strange that it crashed when it did, after scanning all the 200's down to 28.

Original issue reported on code.google.com by JonesC52...@gmail.com on 23 Nov 2010 at 3:48

[GoogleCodeExporter]

OK makes sense to fix syscheck first.  As for the stubs I agree that 
IOS_reloadIOS() will crash.  It would be nice to list them in the report as 
stubbed but I am not sure how Double A figures this out without 
IOS_reloadIOS().  I would have to take a look at his code to see.  This is 
obviously not a priority.  However I do not understand why V13 has no problem 
with ios's with a revision less than 1000. It processes them just fine.  So why 
the change with ios's less than 1000?  Thanks...

Original comment by gsoud...@cox.net on 29 Dec 2010 at 5:35

[GoogleCodeExporter]

What if, you had a list of stubbed versions (like the one in the ios update 
section where it tells you which version of which ios is stubbed) and had the 
stubbed ones reported as "stubbed" w/o reloading them ?

Original comment by crazyrab...@gmail.com on 29 Dec 2010 at 11:42

[GoogleCodeExporter]

Hi, i think the crash is caused by the ios_reloadios on IOS 21.
I'm the creator of pimp my wii and libogc 1.8.5 and 1.8.6 crashes when 
reloading ios 21.

In fact, it's crashing only if i have inited the console with con_initex with a 
"large" console.

I know this bug since months and the only way to prevent this for me is to use 
libogc 1.8.3 or 1.8.4 (i don't remember which one).
It crashes only with ios 21 and not the others. You may choose to not scan this 
ios but if you found a better way, please let me know.

Original comment by mad...@gmail.com on 29 Dec 2010 at 1:57

[GoogleCodeExporter]

Just to report, I have the exception code dump too most every time I run 
syscheck too. But the results are inconsistant depending on how you get to it 
and which ios is being used. In some cases it doesn't run at all. Here is a 
brief summary of my results.

Start Dop-Mii v15.
Select Scan the Wii Internals
Select B to NOT use AHBPROT
Scan starts and gets as far as finishing the report for ios 222 (Hermes v4, 
base 38), then code dumps before starting ios 202 (Hermes v5, base 60).

Start Dop-Mii v15.
Select Scan the Wii Internals
Select A to use AHBPROT
Jumps back to menu. 

Start Dop-Mii v15.
Select IOS36
Press A to use AHBPROT
Select Scan the Wii Internals
Scan starts and gets as far as finishing the report for ios 222, then code 
dumps before starting ios 202.

Start Dop-Mii v15
Select ios 36
Select B to not use AHBPROT
code dumps right away.

Start Dop-Mii v15
Select ios 249 (wanin r19)
Select A to use AHBPROT
Select Scan the Wii internals
Scan starts and gets as far as finishing the report for ios 222, then code 
dumps before starting ios 202.

Start Dop-Mii v15
Select ios 249 (wanin r19)
Select B to not use AHBPROT
Select Scan the Wii internals
Scan starts and gets as far as finishing the report for ios 222, then code 
dumps before starting ios 202.

Interesting to note that ios 36 caused an immediate failure without AHBPROT, 
but with ios 249 it partially worked without AHBPROT.

Since it seemed to fail when hitting ios 202 I deleted it to see if that would 
help. Now it code dumps every time I try to do a syscheck before it even starts 
scanning (well, it gets to the console details and shows 19 ios's safe to test 
then when the screen clears just before the actual scan it code dumps). So I 
reinstalled ios 202, and it made no difference, it still code dumps everytime 
right from the start. I don't know what to make of this part since Dop-Mii was 
atleast doing a partial scan before, and now it isn't. I don't see how 
deleting/reinstalling an ios I wasn't even using could cause such an effect. 

(Oh, BTW, can you fix the main menu. Since 14.x series it's missing a line feed 
or carrage return or something after the AHBPROT notice and this is causing the 
first menu option, IOS select, to looks like this: "t.IOS36" with the letter t 
from the word prompt and closing period wrapping around from the previous line.)

Original comment by robert.k...@comcast.net on 29 Dec 2010 at 2:43

[GoogleCodeExporter]

I removed the prompt code that appears when the screen is filled. Let me know 
if anyone is able to get through syscheck now with it gone.

Original comment by castleva...@yahoo.com on 29 Dec 2010 at 5:21

Attachments:

• trunk.dol

[GoogleCodeExporter]

OK I just tested this release without the prompt code.  The problem still 
exists. I now get a code dump consistently everytime.  I think that madri2 
might be onto something here.  I crash right after scanning ios28.  The next 
one in line is ios 21.  So it is possible that this is the problem.  Not sure 
why the latest release of libogc would cause this...

Original comment by gsoud...@cox.net on 30 Dec 2010 at 4:58

[GoogleCodeExporter]

Well, I see some partial success now. :) But still not working fully. :(

When I do a syscheck right from the main menu after startup, it finished with 
no issues. Though the scan only went as far as ios 28 before completing. Did 
this 2 more times, with the same results. 

Then I loaded ios 36, ran syscheck from the second menu, and again, it scans as 
far as ios 28, then hangs. No code dump, just a locked up console. But then 
when I tried it a second time with ios 36 loaded, it code dumped as soon as the 
scan started. Then when I tried it a 3rd time, it completed (at ios 28). Then I 
tried it a 4th time, it just locked up with no code dump again like the first 
time. 

Then I tried with ios 249, ran syscheck, it completed with no problems after 
ios 28. Tried 2 more times. Each worked no problems. 

Finally, for the last time tried with ios36 again 2 more times, and both times 
worked, completing after ios 28. 

So it does seem to be much more stable now, but it's still seems to be randomly 
inconsistant.

Original comment by robert.k...@comcast.net on 30 Dec 2010 at 12:52

[GoogleCodeExporter]

Here's a few more tests loading the rest of available ios's I have. Most 
interesting is ios 222 and the 'GetNumTicketViews' errors.

ios 60 - code dumps after ios 222.

ios 202 (hermes v5 base 60) - code dumps after ios 222.

ios 222 (hermes v4 base 38) - worked first time, locked up second time at end 
of scan (did not restart app between tries). Tried a 3rd time after rebooting, 
and it worked. Tried a 4th time after restarting app first, and it started 
giving 'GetNumTicketViews too many views: 8' errors after many of the ios (28, 
31, 33, 34, 37, 55 - the rest scrolled off the screen already). I can't save 
the report because, despite giving me the complete message and option to save, 
the console is locked up.

ios 223 (hermes v4 base 38) - Worked all 3 times I tried it

ios 224 (hermes v5 base 57) - Worked first time. Second time locked up after 
ios 28. 3rd time, worked.

ios 236 - mirror of ios 36, with same results as ios 36.

ios 250 - mirror of 249 with version number patched - 1st time, locked up after 
ios 28, 2nd and 3rd times it worked. 

Only under the default ios61 (v4890 - clean unpatched nintendy version) that 
dopmii it starts under, ios223 or ios249 (wanin r19 base 60) does it work 
consistantly every time for me. 

Original comment by robert.k...@comcast.net on 30 Dec 2010 at 2:22

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Ok now it's my turn ^^

Tested with Wii 4.3E with just 3 patched IOS :
236 - Copy of IOS36 v3351 full patched put on slot 236
249 - Waninkoko rev21 base38
250 - Waninkoko rev21 base56
I tested also with default IOS80

With the four, the sysCheck started and worked well until prompting the report 
for IOS28 then showed all the time the same code dump 

http://img211.imageshack.us/img211/4679/img0327w.jpg

Hope this will help you ;)

Original comment by cs-nut...@live.fr on 30 Dec 2010 at 4:28

[GoogleCodeExporter]

Ok, I'm am very dumb. Somehow I ended up testing the last trunk.dol version 
without the 'no ios reload' option in the meta.xml file. <doh!> :/

I redid some of the tests with that option in place, and found it's code 
dumping all the time just like the previous 14.x/15 versions. Even with ios 
249. I'd post a code dump, but the values are different with each scenario and 
don't want to unneccessarly post a dozen different dumps unless requested.

Original comment by robert.k...@comcast.net on 30 Dec 2010 at 5:16

[GoogleCodeExporter]

I also tested the last trunk.dol without the meta.xml but it's because I want 
to fix bug when we use Dop-Mii without AHBPROT and we will see later what's 
going wrong with it ;)

Original comment by cs-nut...@live.fr on 30 Dec 2010 at 5:20

[GoogleCodeExporter]

Over the last three days I've logged in literally about 30 man hours working on 
the source code, doing stack traces, and running other tests across several 
Wii's. I also ran through older builds of libogc closely comparing what changed 
as it developed.

I have a couple basic facts which I know are true:

*Having AHBPROT enabled won't change anything. IOS_ReloadIOS() immediately 
kills AHBPROT so it's not used.
*Similarly, what IOS you use won't change anything as it is immediately 
replaced by the IOS called from IOS_ReloadIOS()

Yet what I see contradicts these facts. The loaded IOS and AHBPROT being in 
effect seem to change things. Furthermore, there seems to be randomness 
associated with when the crashes occur. Lastly, programs like Double A's 
syscheck use nearly identical code yet don't have crashes.

So I head-to-the-table banged for hours trying to come up with an explanation. 
And I finally did.

My best guess (which is also the only thing it could be) is that we're not 
allocating memory properly to satisfy picky, fragile libogc for loading so many 
IOSs in a row. With a fresh opinion I poured through the code again and noticed 
that our memory allocation actually is pretty lame. So, I'll be rewriting a lot 
of syscheck to find out if I'm correct. Assuming I am, I'll turn my attention 
to the report format later.

Thanks for all the information, its really helped.

Original comment by castleva...@yahoo.com on 30 Dec 2010 at 11:29

[GoogleCodeExporter]

This is by far the best sysCheck I've found so far:
http://filetrip.net/g25125163-sysCheck.html

Maybe you could contact the Author of this homebrew to help/advise you about 
some stuff regarding the sysCheck.

Original comment by crazyrab...@gmail.com on 31 Dec 2010 at 3:34

[GoogleCodeExporter]

So, it's been a few months now. Just wondering if there is any update on how 
this is going? --  I know, rewrites take time, but maybe there is a hint of 
positive news to wet our mouths with. :) 

Original comment by robert.k...@comcast.net on 21 Apr 2011 at 6:10

[GoogleCodeExporter]

Original comment by castleva...@yahoo.com on 13 Jul 2011 at 3:27

• Changed state: Fixed