Page 1 of 2

FreeMem()

Posted: Wed Dec 15, 2010 4:13 pm
by some1
Here's a quick update so GAME_FREEMEM_ADDR can be an array

Code: Select all

#ifdef GAME_FREEMEM_ADDR
void FreeMem()
{
	u32 i;
	SceUID memids[] = GAME_FREEMEM_ADDR;
	
	for(i = 0; i < sizeof(memids)/sizeof(u32); i++)
	{
		int ret = sceKernelFreePartitionMemory(*(SceUID*)memids[i]);
		if (ret < 0)
		{
			LOGSTR2("--> ERROR 0x%08lX FREEING PARTITON MEMORY ID 0x%08lX\n", ret, *(SceUID*)memids[i]);
		}
	}
}
#endif
Not sure if this was the best way to do it, but just a quick fix, I've only tested with two addrs's in the array.

Thanks to Freddy for helping fix a problem in the above code

Re: FreeMem()

Posted: Wed Dec 15, 2010 4:41 pm
by FrEdDy
some1 wrote:Here's a quick update so GAME_FREEMEM_ADDR can be an array

Code: Select all

#ifdef GAME_FREEMEM_ADDR
void FreeMem()
{
	u32 i;
	SceUID memids[] = GAME_FREEMEM_ADDR;
	
	for(i = 0; i < sizeof(memids)/sizeof(u32); i++)
	{
		int ret = sceKernelFreePartitionMemory(*(SceUID*)memids[i]);
		if (ret < 0)
		{
			LOGSTR2("--> ERROR 0x%08lX FREEING PARTITON MEMORY ID 0x%08lX\n", ret, *(SceUID*)memids[i]);
		}
	}
}
#endif
Not sure if this was the best way to do it, but just a quick fix, I've only tested with two addrs's in the array.

Thanks to Freddy for helping fix a problem in the above code
Meh,I don't see it as a fix :P it's just a fix for your exploit

Re: FreeMem()

Posted: Wed Dec 15, 2010 4:44 pm
by JJS
In the long run it will become necessary to have the ability for freeing more than one memory allocation. This will break all existing GAME_FREEMEM_ADDR definitions in exploit_config.h until they are updated to be arrays.

A quick correction though:

Code: Select all

#ifdef GAME_FREEMEM_ADDR
void FreeMem()
{
   u32 i;
   SceUID memids[] = GAME_FREEMEM_ADDR;
   int ret;
   
   for(i = 0; i < sizeof(memids)/sizeof(u32); i++)
   {
      ret = sceKernelFreePartitionMemory(*(SceUID*)memids[i]);
      if (ret < 0)
      {
         LOGSTR2("--> ERROR 0x%08lX FREEING PARTITON MEMORY ID 0x%08lX\n", ret, *(SceUID*)memids[i]);
      }
   }
}
#endif
Edit: Corrected stupid mistakes.

Re: FreeMem()

Posted: Wed Dec 15, 2010 4:53 pm
by m0skit0
I see it useful, good improvement and good idea.

And sorry but

Code: Select all

SceUID memids[];
makes no sense. Looping through an array that you don't even declare its contents, address or length :?

Also having

Code: Select all

sizeof(memids)/sizeof(u32)
on the for sentence is awful. Why compute this division on every loop? Better use another variable like

Code: Select all

num_memids = sizeof(memids)/sizeof(u32)
Anyway, I think the best solution is to declare a global external array on the exploit header file and use that. Also it would be a good idea to provide a wrapper to access those variables, not accessing directly to them but through functions.

Re: FreeMem()

Posted: Wed Dec 15, 2010 5:02 pm
by some1
meh, do what ever you want, it was just a quick fix for what I'm working on, and also, I got

Code: Select all

sizeof(memids)/sizeof(u32)
From DeleteAllThreads()

Re: FreeMem()

Posted: Wed Dec 15, 2010 6:23 pm
by JJS
To be fair, this is really just in line with the existing code for freeing the threads and semaphores etc.

Re: FreeMem()

Posted: Thu Dec 16, 2010 12:25 am
by wololo
m0skit0 wrote:

Code: Select all

sizeof(memids)/sizeof(u32)
on the for sentence is awful. Why compute this division on every loop? Better use another variable like
"sizeof" is computed at compile time So I'm pretty sure the compiler optimizes this division for you... I also happen to know what I do from time to time. ;)
Your suggestion, on the other hand, introduces a runtime variable and risks of side effects.
You can quote me on this.

also, even if you assume that the compiler is dumb and wil do the division every time, making a division every loop on an array of a dozen entries will not have any performance impact, it's nothing compared to, for example, opening the Debug log file once.

In other words, this code is exactly what we want in that kind of case, not an additional variable

Re: FreeMem()

Posted: Thu Dec 16, 2010 7:46 am
by m0skit0
It's very ugly and anyway as you say the compiler will optimize it for you (whether you use a local variable or not). Also I've not yet seen on HBL a local variable going corrupt, I don't know why you say that about it.

Anyway, I'm not going to discuss about this since it's not really relevant :mrgreen:

And to some1, don't feel upset, this is the kind of discussions we have around here. If you're not ready to discuss your code and/or ideas with other developers, I suggest you to not get involved in open source projects. We're just trying to make it shine 8-) :lol: and also try to avoid potential bugs. Also a big part of this is learning from each other.

Re: FreeMem()

Posted: Thu Dec 16, 2010 8:02 am
by wololo
You can't say in the same post that my code is "ugly" and then say you won't discuss it, you're just trying to dodge your mistake here.

I didn't say local variables would get corrupt, I said they introduced risks of side effects.

here's how:

Code: Select all

int var = sizeof(A)/sizeof(B);

[...]
var = 0;
[...]
for (i = 0; i < var; ++i) {
stuff;
}

What do you think about the following?

Code: Select all

int var1 = sizeof(A)/sizeof(B);
int var2 = var1;
int var3 = var2;
int var4 = var3;

for (i = 0; i < var4; ++i) {
stuff;
}
Because in essence, that's what you're suggesting, man.

Re: FreeMem()

Posted: Thu Dec 16, 2010 8:16 am
by JJS
Well, sizeof() will be shortened to a number by the compiler so there is indeed no problem.


The first error scenario could be avoided by using the "const" modifier on the variable.

I don't get the point of the second one tbh. If it is about whether the compiler can optimize the unnecessary variables away, I don't know.