Closed GoogleCodeExporter closed 9 years ago
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
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
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
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
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:
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
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
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
[deleted comment]
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
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
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
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
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
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
Original comment by castleva...@yahoo.com
on 13 Jul 2011 at 3:27
Original issue reported on code.google.com by
JonesC52...@gmail.com
on 23 Nov 2010 at 3:48