run out of memory while repeat save and load process

[calais007]

I have noticed a bug at all most all jpcsp version,
this issue can be reproduced if we repeat save and load process in game,
it can be much easier to reproduce when running Tokimeki Memoriaru 4.
Dose jpcsp always create a new thread while loading sectors from UMD?


console message:

at jpcsp.Allegrex.compiler.RuntimeThread.run(RuntimeThread.java:51)
java.lang.OutOfMemoryError
java.lang.OutOfMemoryError
at java.io.RandomAccessFile.readBytes(Native Method)
at java.io.RandomAccessFile.read(Unknown Source)
at jpcsp.filesystems.umdiso.UmdIsoReader.readSectors(UmdIsoReader.java:1
57)
at jpcsp.filesystems.umdiso.UmdIsoFile.read(UmdIsoFile.java:301)
at java.io.InputStream.read(Unknown Source)
at jpcsp.filesystems.umdiso.UmdIsoFile.readFully(UmdIsoFile.java:236)
at jpcsp.util.Utilities.readFully(Utilities.java:321)
at jpcsp.HLE.modules150.IoFileMgrForUser$IOAsyncReadAction.execute(IoFil
eMgrForUser.java:479)
at jpcsp.HLE.modules150.IoFileMgrForUser.doStepAsync(IoFileMgrForUser.ja
va:1052)
at jpcsp.HLE.modules150.IoFileMgrForUser.hleAsyncThread(IoFileMgrForUser
.java:976)
at jpcsp.HLE.modules150.ThreadManForUser.hleKernelAsyncLoop(ThreadManFor
User.java:1385)
at sun.reflect.GeneratedMethodAccessor17.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at jpcsp.HLE.modules.HLEModuleFunctionReflection.executeInner(HLEModuleF
unctionReflection.java:389)
at jpcsp.HLE.modules.HLEModuleFunctionReflection.execute(HLEModuleFuncti
onReflection.java:345)
at jpcsp.HLE.modules.HLEModuleManager.handleSyscall(HLEModuleManager.jav
a:388)
at jpcsp.HLE.SyscallHandler.syscall(SyscallHandler.java:111)
at jpcsp.Allegrex.compiler.RuntimeContext.syscall(RuntimeContext.java:67
9)
at _S1_3_8000040.s(_S1_3_8000040.java:0)
at _S1_3_8000040.exec(_S1_3_8000040.java)
at jpcsp.Allegrex.compiler.RuntimeContext.runThread(RuntimeContext.java:
710)
at jpcsp.Allegrex.compiler.RuntimeThread.run(RuntimeThread.java:51)

[calais007]

I think it exist a memory leak issue in UmdIsoReader.java,
There are two containers that named
private HashMap<String, Iso9660File> fileCache = new HashMap<String, Iso9660File>();

and

private HashMap<String, Iso9660Directory> dirCache = new HashMap<String, Iso9660Directory>();

I have reviewed this file and I just see that jpcsp ONLY do add item into container but without remove the added item, in my debugging, every time JPCSP read a file from UMD (e.g, in Game NOW Loading), then memory usage space increased, Java GC never free a reference that still in container. Maybe JPCSP should remove the unused items from container to prevent memory leak.

Sorry for my bad English

[gid15]

I think it exist a memory leak issue in UmdIsoReader.java,
There are two containers that named
private HashMap<String, Iso9660File> fileCache = new HashMap<String, Iso9660File>();

and

private HashMap<String, Iso9660Directory> dirCache = new HashMap<String, Iso9660Directory>();

I have reviewed this file and I just see that jpcsp ONLY do add item into container but without remove the added item, in my debugging, every time JPCSP read a file from UMD (e.g, in Game NOW Loading), then memory usage space increased, Java GC never free a reference that still in container. Maybe JPCSP should remove the unused items from container to prevent memory leak.

Sorry for my bad English

Try to do the next logical thing: look at how many objects are stored in the fileCache and dirCache. There should be only a few 100s, depending on how many files are stored in your ISO. And each object contains only a few bytes. So how can this explain that your memory usage is increasing of 100s of MB?
If you want to help, please post a complete log file in the corresponding game thread.

[calais007]

[/quote]
Try to do the next logical thing: look at how many objects are stored in the fileCache and dirCache. There should be only a few 100s, depending on how many files are stored in your ISO. And each object contains only a few bytes. So how can this explain that your memory usage is increasing of 100s of MB?
If you want to help, please post a complete log file in the corresponding game thread.
[/quote]

Hi gid15
You are right fileCache and dirCache are less than 100s, but JPCSP always memory leak on each loading process, I added some logs while reader sectiors from UMD, you will see the size of fileCache and dirCache on log file.

[gid15]

Code:

Shader error log: Vertex shader was successfully compiled to run on hardware. Fragment shader failed to compile with the following errors: ERROR: 0:151: error(#202) No matching overloaded function found texture2DProj ERROR: 0:151: error(#160) Cannot convert from 'const float' to 'unsigned int' ERROR: error(#273) 2 compilation errors. No code generated

Your log is showing an interesting error message that I would to investigate.
With r2363, could you start Jpcsp, enable DEBUG log (before loading the UMD), load your UMD and post the generated log file?

Thanks!

[calais007]

Code:

Shader error log: Vertex shader was successfully compiled to run on hardware. Fragment shader failed to compile with the following errors: ERROR: 0:151: error(#202) No matching overloaded function found texture2DProj ERROR: 0:151: error(#160) Cannot convert from 'const float' to 'unsigned int' ERROR: error(#273) 2 compilation errors. No code generated

Your log is showing an interesting error message that I would to investigate.
With r2363, could you start Jpcsp, enable DEBUG log (before loading the UMD), load your UMD and post the generated log file?

Thanks!

Hi gid15
I saw log show
"Using shader version 140, available shading language version 400"
My video card is ATI Radeon 5700 series

[gid15]

Code:

Shader error log: Vertex shader was successfully compiled to run on hardware. Fragment shader failed to compile with the following errors: ERROR: 0:151: error(#202) No matching overloaded function found texture2DProj ERROR: 0:151: error(#160) Cannot convert from 'const float' to 'unsigned int' ERROR: error(#273) 2 compilation errors. No code generated

Your log is showing an interesting error message that I would to investigate.
With r2363, could you start Jpcsp, enable DEBUG log (before loading the UMD), load your UMD and post the generated log file?

Thanks!

Hi gid15
I saw log show
"Using shader version 140, available shading language version 400"
My video card is ATI Radeon 5700 series

This is a strange error message. It is referring texture2DProj but this function should not be used for a version 140...
Could you try to change jpcsp/graphics/shader.frag, line 73:
Old:

Code:

#define TEXTURE_2D_PROJ texture2DProj

New:

Code:

#define TEXTURE_2D_PROJ textureProj

Thanks!

[Carlos007]

[/quote]
This is a strange error message. It is referring texture2DProj but this function should not be used for a version 140...
Could you try to change jpcsp/graphics/shader.frag, line 73:
Old:

Code:

#define TEXTURE_2D_PROJ texture2DProj

New:

Code:

#define TEXTURE_2D_PROJ textureProj

Thanks!
[/quote]


Hi gid15
I have no idea why my previous account was been banned by system,
but it is not important for this case.

After upgrade ATI driver to catalyst 1.19, this error message was disappeared, but another message display , the new error log shows "Validation failed! - Different sampler types for same sample texture unit in fragment shader.", As I know, this is a bug of ATI driver, hope this problem would fix in new driver. debug log attached


Thanks