4.9.0 strange freeze after inactivity

[hexaae]

Whole WB (Picasso96 RTG) freezed (no mouse movements) with 4.9.0 public release after long time run... Still have to find a pattern but it already happened twice when reopening WinUAE window (I use auto-iconify, no audio, when focus is lost) after some hours.
Could be just some buggy Amiga software I run before I iconified WinUAE which corrupted something in mem, but everything was working fine 'till then. I'm investigating...

[paraj]

I don't know if it will help in this case, but in general you can right click on application/tasks in task manager and select "create dump file" even when the process is frozen. This will create a ".dmp" file (windows should show where it's located).

Attaching that dmp-file isn't guaranteed to help, but it won't hurt. I don't think Toni publishes PDB files for WinUAE, but anyone with a debugger could then see if it's something "obvious".

[hexaae]

Oh, didn't know, thanks.

[Gilloo]

alt-F12 then Cancel ?

[Toni Wilen]

Crash dump won't help if emulator itself hasn't frozen (F12 still works etc).

[hexaae]

I was able to open F12 GUI when WB was frozen and even mouse inputs ignored.

[hexaae]

Still investigating... in the meanwhile I can confirm (reproduced every time) that on the long run (hours...) something happens and WinUAE 4.9.0 becomes progressively slower.
Rebooting Workbench won't help, so it's not something on the Amiga software side... This visible slow down (slow at opening drawers, slow to process images with ArtEffect etc..) won't go away 'till I fully quit and re-launch WinUAE task (Restart button won't help either).
I use JIT ON for Workbench (RTG latest P96), usually switch it temporary OFF before I run native games.

[Mclane]

Mem leak?

Open task manager when its doing this and see how much mem is being consumed..

Not sure if it will reveal anything but anything must be worth a look..

[hexaae]

@Toni
Is there something I can do (dump or whatever...) when the slow-down happens? Seems totally random, or at least can't find a pattern yet but definitely it randomly happens...

[NoX1911]

Maybe you can narrow it down even further by testing previous beta versions.
And in a perfect world you would bisect the corresponding versions then. But you probably don't want to try that if you've never worked with 'git' before.

[Toni Wilen]

Download Process Explorer and check winuae.exe Performance/Handles and Virtual memory/physical memory panel counts stays stable.

If you have sound playing, does it keep working normally?

Does inserting/ejecting disk still work? (OSD led track count changes if trackdisk.device is alive).

Does changing D3D mode wake it up? Or fullscreen<>windowed toggle?

[hexaae]

Originally Posted by Toni Wilen

Download Process Explorer and check winuae.exe Performance/Handles and Virtual memory/physical memory panel counts stays stable.

If you have sound playing, does it keep working normally?

Does inserting/ejecting disk still work? (OSD led track count changes if trackdisk.device is alive).

Does changing D3D mode wake it up? Or fullscreen<>windowed toggle?

Ok will check with Process Explorer...
Yep, sound is ok (Delitracker, AmigaAMP68K...).
Yep disk is still working...
D3D mode switch not tested. I'll try next time to switch back to DX9...

[hexaae]

@Toni
One strange thing I've just noticed is that Working Set physical mem is constantly increasing every 3 secs +4KB...



532.016... 532.020... 532.024... and so on. Will keep it running and report back...

[hexaae]

After some hours running:

[Toni Wilen]

Working set can rise because memory pages (page is 4k) that have not yet been accesses are not counted (=are not mapped to winuae.exe address space yet) and this includes Amiga side RAM. This makes it difficult to know if it is actual memory leak or normal, for example some Amiga program using different parts of memory or Amiga side memory getting fragmented which appears as larger working set without change in Amiga side free RAM.

[hexaae]

The others are ok (Handles, I/O Other...)?

[Toni Wilen]

Possibly. Depends on how much RAM your config has.

If you can duplicate the problem relatively easier, try narrowing down the beta that introduced it (usually binary search works the best but check first beta first).

But first 100% confirm it does not happen with 4.4. Do not assume anything because some driver/windows/something update can always cause unexpected side-effects.

[hexaae]

Ooops, I've found I forgot the option "Misc > Allow native code = ON"... Could this lead to JIT corruption (still have no idea what that option is exactly for honestly)?
EDIT: http://eab.abime.net/showthread.php?t=96702 uhm... I never installed x86 custom libs for WinUAE so I guess it can't have nothing to do with my JIT crashes...

[hexaae]

Originally Posted by Toni Wilen

But first 100% confirm it does not happen with 4.4. Do not assume anything because some driver/windows/something update can always cause unexpected side-effects.

Running 4.4.0 for 9 hours, no slowdown...



EDIT: in the meanwhile I made a test and discovered the slowdown is exactly like when I completely disable JIT at Workbench. So adding this clue to the fact that I also experienced "JIT serious error: Could not allocate block pool!" crashes, 95% is some problem with JIT on the long run in the new 4.9.x... Replicated the problem also using 040 emu (my default cfg is 060).

[Toni Wilen]

Originally Posted by hexaae

Running 4.4.0 for 9 hours, no slowdown...

Can you almost immediately see the difference between 4.4.0 and 4.5/4.9.x if you run 2 versions simultaneously and keep both process explorer panels open? It would make finding the first non-working version much quicker.