• 1
  • 2
  • 3
  • 4(current)
  • 5
  • 6
  • 7
Random GUI Lockups in newer SVN builds
#46
O yea I see what your saying spiff its majortom's bug cool at least thats another one out of the way. I really want to get my bug fixed and if the only way of getting it is by doing what jmarshall was saying then I dont think I can do it. For one thing is I'd need a debug bios problem is my modchip has only got one bank on it so I fail at this point.

Any way to get a debugger going some other way? Or even better anyone else replicate this bug who has what jmarshall said we need (Debugging tools).
#47
@willers.nail: That's why his instructions tell you to load a debug bios with the phoenix bios loader.
#48
Ok thanks I see what your saying so PBL will allow me to run a debug bios from the hard drive. Ok Ill head over to xboxscene to see how to use this and hopefully I can figure out how to do what Jmarshall has said about getting a debugger attached.

Hey Jmarshall I hate asking but could you give me a step by step guide to getting this all setup as Im still a bit unsure of things like when you say
Quote:Then it's just a matter of deploying to appropriate folder, building a debug build, and running with the debugger attached.
#49
Then you're probably not the one to do it. I don't have time to help I'm afraid. Perhaps someone else can. I can, however give you a link:

Search google for "hydras world retail to debug"

Note that you only have to do the bit about transferring the XDK stuff over to the xbox. Then grab a debug bios and Phoenix Bios Loader, and run that. You'll get the debug dash.

Then follow the hydrasworld article about debugging on xbox, and apply said knowledge to XBMC.
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.


Image
#50
Cool I appreciate all the help Jmarshall Ill keep trying what you've said in the meantime.

Thanks
#51
I tried debugging, but the error doesn't show up that often.

I'm now trying to identify the bug by adding loging.
The latest result is that the 'FrameMove()' crash is caused by 'ReadInput()'

Code:
19:00:49 M: 39251968   ERROR: exception in CXBApplicationEx::ReadInput()
19:00:49 M: 39251968   ERROR: exception in CApplication::FrameMove()

Next step is adding more debug code to ReadInput().
#52
DrDDT Wrote:I tried debugging, but the error doesn't show up that often.

Next step is adding more debug code to ReadInput().

The good news: I know the exact funtion call where the exception occurs:

File: XBInputEx.cpp
Function: VOID XBInput_GetInput( XBIR_REMOTE* pIR_Remote)
Line: if (ERROR_SUCCESS == XInputGetState( g_IR_Remote[i].hDevice, (XINPUT_STATE*) &g_InputStatesEx[i] ))

The bad news: This is a XDK call, so I cannot find out why it is happening.

Other potential usefull information:

My Gamepad is in port 0
i=port with IR dongle (in my case, port 1)

I tried to reset the port after the exception occured, but this didn't help.
#53
Hmm, I have a sneaky suspicion it's because we are using extremely old reverse engineered code for this, and that it was simply gotten wrong. One thing I'm worried about is XGetInputState() fills a XINPUT_STATE struct with data, and one presumes that it could thus write as many as sizeof(XINPUT_STATE) bytes to the pointer you pass in. Whether it does so or not for the remote I have no idea, but at least for the gamepad it should be assumed to write that many bytes. Now, we have an XINPUT_STATEEX, which I suspect may be smaller than XINPUT_STATE - this is not good.

I shall confirm the sizes of XINPUT_STATEEX and XINPUT_STATE to check whether this could be it.

Cheers,
Jonathan
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.


Image
#54
Ok, above theory may be the cause, but it's a stab in the dark entirely, as I don't get said error on my xbox.

To test, you need to check for corruption of memory around the g_InputStatesEx structure. So what I suggest you do is create a temporary backup of g_InputStatesEx before the XGetInputState() call, then do the call. Then compare to your backup outside of the particular state you're reading.

i.e.

Code:
memcpy(backup, g_InputStatesEx, sizeof(backup));
      ZeroMemory( &g_InputStatesEx[i], sizeof(XINPUT_STATEEX) );
      if (ERROR_SUCCESS == XInputGetState( g_IR_Remote[i].hDevice, (XINPUT_STATE*) &g_InputStatesEx[i] ))
      {
        // compare from backup to g_InputStatesEx;
        for (int j = 0; j < 4; j++)
        {
          if (j != i && memcmp(&backup[j], &g_InputStatesEx[j], sizeof(XINPUT_STATEEX)) != 0)
            CLog::Log(LOGFATAL, "Holy shit, batman, we're as corrupt as the Penguin!");
        }

If that is indeed the fault, you should get output from it before you get hit with an exception.

The fix is to extend XINPUT_STATE_EX as follows:

Code:
typedef struct _XINPUT_STATEEX
{
#pragma pack( push, before_header )
#pragma pack(1)
  DWORD dwPacketNumber;
  union // added by JM to attempt to fix the memory corruption issues - XGetInputState() writes to an
        // XINPUT_STATE pointer, so we pad this structure out so that it's at least sizeof(XINPUT_STATE)
  {
    XINPUT_GAMEPAD Gamepad;
    XINPUT_IR_REMOTE IR_Remote;
  };
#pragma pack( pop, before_header )
}
XINPUT_STATEEX, *PXINPUT_STATEEX;

Cheers,
Jonathan
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.


Image
#55
i've also experienced these random lockups when browsing the GUI.
These happens normally when i play a mp3-file and select a new song.
After som trying and error i managed to reproduce the lockups.

The lockups seems to be related to the rolling text in the left bottom corner.
The lockups occur when i selected a new song when the rolling text is at a spesific position.This explain the randomness people experienced.

I'm not a programmer but hope this information can be helpfull
#56
Actually, that's not the same issue as this particular post refers to, but yes, it is something else that has been an issue for some. It'd be appreciated if you could tell me exactly which version you are running, as there was a change or two in that file not too long ago.

In addition, if you could tell me how to get it reproducible (eg practise with a particular file (it'll be a combination of 2 files in a row) and then making those files available) it would be most helpful - once I can reproduce it, fixing it will be straight forward.

Thanks,
Jonathan
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.


Image
#57
SteroNote Wrote:i've also experienced these random lockups when browsing the GUI.
These happens normally when i play a mp3-file and select a new song.
After som trying and error i managed to reproduce the lockups.

The lockups seems to be related to the rolling text in the left bottom corner.
The lockups occur when i selected a new song when the rolling text is at a spesific position.This explain the randomness people experienced.

I'm not a programmer but hope this information can be helpfull

I think you are experiencing the exact same problem as I described in this thread: http://forum.xbmc.org/showthread.php?tid=33209
#58
jmarshall Wrote:Actually, that's not the same issue as this particular post refers to, but yes, it is something else that has been an issue for some. It'd be appreciated if you could tell me exactly which version you are running, as there was a change or two in that file not too long ago.

In addition, if you could tell me how to get it reproducible (eg practise with a particular file (it'll be a combination of 2 files in a row) and then making those files available) it would be most helpful - once I can reproduce it, fixing it will be straight forward.

Thanks,
Jonathan

I also tried to reproduce this issue with 2 (specific) files in a row. But it is not reproducable this way. So I don't think it is related to files being played. I just disabled automatic fan speed control to see whether this fixes the problem. I hasn't hang since (over an hour now), so this *maybe* the location to look at. Maybe the other reported could also try this and see whether it also fixes his problem...
#59
arnova Wrote:I also tried to reproduce this issue with 2 (specific) files in a row. But it is not reproducable this way. So I don't think it is related to files being played. I just disabled automatic fan speed control to see whether this fixes the problem. I hasn't hang since (over an hour now), so this *maybe* the location to look at. Maybe the other reported could also try this and see whether it also fixes his problem...

It just froze again. So we need to look in another direction for this issue (than the automatic fan speed control)... Next I will try to downgrade my XBMC to older versions (but newest than Jan-2008, as this is the version that doesn't suffer from this issue...
#60
I've given the files to jmarshall and he said to look into it

i suggest that after a lockup you remember/notice the position of the rolling text. To reproduce the lockup you play the last song which was playing allright and then when the rolling text matches the screen from the previous lockup, select a new song.This is how i manage to reproduce the lockup

Not every mp3 has the potential to lockup, but the trend is old mp3. Therfore its important to remember the song before lockup if you want to reproduce it.

when i reproduce the lockup, the debug log for the last action(select) is

00:46:29 M: 40247296 DEBUG: CApplication::OnKey: 256 pressed, action is 7
00:46:29 M: 40247296 DEBUG: CPlayerCoreFactor::GetPlayers(F:\Music\Top 100 One Hit Wonders -2002\74 - Rebirth Of Slick (Cool Like Dat).mp3)
00:46:29 M: 40247296 INFO: PAPlayer: End of playback reached
00:46:29 M: 41451520 INFO: MP3Codec: Loaded decoder at 00B05010
00:46:29 M: 40914944 INFO: PAP Player: Playing F:\Music\Top 100 One Hit Wonders -2002\74 - Rebirth Of Slick (Cool Like Dat).mp3
00:46:29 M: 40263680 DEBUG: PAPlayer: Thread started
00:46:29 M: 40263680 DEBUG: Playback has started
00:46:29 M: 40263680 DEBUG: CGUIInfoManager::SetCurrentSong(F:\Music\Top 100 One Hit Wonders -2002\74 - Rebirth Of Slick (Cool Like Dat).mp3)
00:46:29 M: 40120320 INFO: AudioDecoder: File is queued
00:46:29 M: 40243200 DEBUG: Loading additional tag info for file F:\Music\Top 100 One Hit Wonders -2002\74 - Rebirth Of Slick (Cool Like Dat).mp3

the debug log for a lockup after just playing around randomly with mp3

00:56:12 M: 40222720 DEBUG: CApplication::OnKey: 11 pressed, action is 7
00:56:12 M: 40222720 DEBUG: CPlayerCoreFactor::GetPlayers(F:\Music\Top 100 One Hit Wonders -2002\13 - The Hustle by Van McCoy(1975.mp3)
00:56:12 M: 40222720 INFO: PAPlayer: End of playback reached
00:56:12 M: 41422848 INFO: MP3Codec: Loaded decoder at 00AA4250
00:56:12 M: 40878080 INFO: PAP Player: Playing F:\Music\Top 100 One Hit Wonders -2002\13 - The Hustle by Van McCoy(1975.mp3
00:56:12 M: 40226816 DEBUG: PAPlayer: Thread started
00:56:12 M: 40226816 DEBUG: Playback has started
00:56:12 M: 40206336 DEBUG: CGUIInfoManager::SetCurrentSong(F:\Music\Top 100 One Hit Wonders -2002\13 - The Hustle by Van McCoy(1975.mp3)
00:56:12 M: 40157184 INFO: AudioDecoder: File is queued
00:56:12 M: 40206336 DEBUG: Loading additional tag info for file F:\Music\Top 100 One Hit Wonders -2002\13 - The Hustle by Van McCoy(1975.mp3
00:56:12 M: 40206336 ERROR: exception in CApplication::Render()


I think the bug is related to the rolling text and the mp3 tag, but thats my guess
  • 1
  • 2
  • 3
  • 4(current)
  • 5
  • 6
  • 7

Logout Mark Read Team Forum Stats Members Help
Random GUI Lockups in newer SVN builds1