search

eksdii0o3 / valentine-hbl

Automatically exported from code.google.com/p/valentine-hbl
Other
0 stars 0 forks source link

Rev 79: Bug OR HBL is becoming too big #128

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
HBL is giving weird errors at runtime, see m0skit0's comments in:
http://code.google.com/p/valentine-hbl/source/detail?r=79

We currently believe the problem is that the debug HBL binary is too big,
and ends up getting overwritten by the stack, or something nasty like that.

It could also be a stupid bug somewhere.

This basically prevents any progress on the project, so this needs to be
fixed asap

Original issue reported on code.google.com by wagic.the.homebrew@gmail.com on 13 May 2010 at 11:04

GoogleCodeExporter commented 9 years ago 
Several people have reported failures with the DEV version posted on my 
website. I 
believe this is related to this problem

Original comment by wagic.the.homebrew@gmail.com on 14 May 2010 at 1:36

GoogleCodeExporter commented 9 years ago 
Whenever I compile Rev79 Debug Version or Distrib Version, I always get a 
message on
the HBL Menu which reads" You Forgot To Make Clean". Even though I have 
downloaded a
fresh version of the HBL from the SVN I get this message and I never got this 
message
before on previous versions. The Debug Version will not load any homebrew, but 
the
Distrib Version loads all the homebrew that I have tested working before. Even 
DOSBox
works now using Distrib version. I am doing this on my PSPGo with 6.20.

Original comment by JUN1989@gmail.com on 14 May 2010 at 8:33

GoogleCodeExporter commented 9 years ago 
and... did you try to type "make clean" ? Also, that's completely unrelated to 
this 
ticket, so please don't reply here, instead, go to advvacnedpsp's forums, thanks

Original comment by wagic.the.homebrew@gmail.com on 14 May 2010 at 8:41

GoogleCodeExporter commented 9 years ago 
I'm running Debian lenny using the full pspsdk.  I've compiled r79 maybe three
different times with 'make distrib' and on my 3001 6.20 it works fine.  With 
that
said, the bug must be in DEBUG as I've had some previous revisions compile 
DEBUG fine
and while distrib would stop for simple bracket errors.  Perhaps now it's just 
the
other way around, only it's not a code bug in the debug version, it's a logical 
error
that doesn't cause a compile error.  Just a thought.

Original comment by Cathesdus on 14 May 2010 at 3:49

GoogleCodeExporter commented 9 years ago 
Confirmed DEBUG does not work.  Freees at Freeing memory then shuts off.  
dbglog is
full of nid table full errors.

Original comment by Cathesdus on 14 May 2010 at 5:57

GoogleCodeExporter commented 9 years ago 
I do agree with Cathesdus. I'm also running Debian and the debug version do not 
work
(although it compiles fine), while distrib version works flawlessly.

Original comment by ametric@gmail.com on 14 May 2010 at 9:52

GoogleCodeExporter commented 9 years ago 
I've got some code ready that
1) Reduces the size of hbl.bin from 51kB to 38kB without loosing functionality
2) Loads hbl.bin at 0x08804000 instead of the previous location (it is kind of a
requirement for my change anyways).

This is basically achieved by doing the hole memory cleanup / tables building 
in a
separate bin that gets unloaded after doing its job. Therefore the HBL binary 
only
does syscall estimates + hooks + displaying menu + running homebrews

@m0skit0: I think my change may be compatible with the things you discussed 
earlier,
but I'll wait 24h before submitting, in case you have something better and/or 
don't
want to deal with the hassle of code merge.

Original comment by wagic.the.homebrew@gmail.com on 15 May 2010 at 7:27

GoogleCodeExporter commented 9 years ago 
After extensive testing, I still have issues with the new code. So I think this 
is 
not necessarily related with the size of HBL.
Some global variables get randomly overwritten, or act as if they were never 
initialized in the first place.
I'm strengthening the flags in the Makefile to see if we are missing some 
important 
warnings somewhere.

Any reason why global variables would be overwritten ?

Original comment by wagic.the.homebrew@gmail.com on 18 May 2010 at 3:39

GoogleCodeExporter commented 9 years ago 
I think I already stated that global variables actually do not get a reserved 
memory
space. I mean, the memory those variables are referring to is not allocated, 
thus any
thread/stack can overwrite them.

Original comment by ametric@gmail.com on 19 May 2010 at 1:10

GoogleCodeExporter commented 9 years ago 
Errrm... that's a bit weird, don't you think? How do regular C programs handle 
globals?
if a global can get overwritten at any point, there is no way to code...

if a global is an int or a pointer, it takes 4 bytes...if you're telling me that
these 4 bytes can be erased by anything else, I don't believe you.

If you're telling something else, then I didn't understand what you mean...

Original comment by wagic.the.homebrew@gmail.com on 19 May 2010 at 1:28

GoogleCodeExporter commented 9 years ago 
I believe global variables are automatically allocated (in the heap ?) so our 
problem
might be heap corruption.

Original comment by wagic.the.homebrew@gmail.com on 19 May 2010 at 1:40

GoogleCodeExporter commented 9 years ago 
Global variables are not automatically allocated. Where's the code for that? 
Remember
that we're exploiting here, we are not executing a normal program. 

Normal programs get their .bss section (which is where global variables are 
located)
effectively allocated by the OS, but that's not our case. We have no normal
executable structure, and .bss section is NOT allocated, thus our global 
variables
are "on the fly". If you check hbl.bin, you'll see that. 

And yes, I'm telling these 4 bytes can be erased by anything else. And given the
amount of global variables we're using, it's kind of normal if HBL code is too 
close
to stack (which it's how it was before). You can maybe try and put some of those
variables not global and see what happens.

Also the fact that the distrib version, which is smaller, does not suffer from 
this
bugs seems to confirm my hypothesis. 

Anyway, if you have another explanation, I'm all ears.

Original comment by ametric@gmail.com on 20 May 2010 at 10:28

GoogleCodeExporter commented 9 years ago

Original comment by ametric@gmail.com on 20 May 2010 at 10:29

GoogleCodeExporter commented 9 years ago 
Here another example about global variables being a problem:
http://advancedpsp.tk/foro_es/viewtopic.php?p=7762#p7762

Original comment by ametric@gmail.com on 20 May 2010 at 10:52

GoogleCodeExporter commented 9 years ago 
in that case, how about putting a big "GlobalVars" struct in a specified 
position in
the scratchapd, where we would put all globals ?
Then a function that needs to use the globals first needs to reference that 
known
location:

typedef struct
{
 int malloc_init,
 int gY,
 nidTable * nid_table,
  ...
} tGlobalVars

in main:
memset(0, GLOBAL_VARS_ADDR, sizeof(tGlobalVars))
(to init it...)

and everytime we want to access it:
tGlobalVars* g = (tGlobalVars*) GLOBAL_VAR_ADDR

This way our globals are not globals anymore, they are a bunch of variables in a
known location in the scratchpad

Original comment by wagic.the.homebrew@gmail.com on 20 May 2010 at 11:12

GoogleCodeExporter commented 9 years ago 
Shit, I always miss your comments... 

Well I agree with putting them into the scratchpad. This way they'll be REAL 
globals,
not memory addresses not even allocated and anything can overwrite them :P

It would be way better if we wouldn't have to use global variables at all, but 
given
the current HBL structure, I don't think this is possible.

Original comment by ametric@gmail.com on 23 May 2010 at 2:21

GoogleCodeExporter commented 9 years ago 
fixed in r85, please verify

Original comment by wagic.the.homebrew@gmail.com on 26 May 2010 at 11:30

GoogleCodeExporter commented 9 years ago 
Issue 277 has been merged into this issue.

Original comment by wagic.the.homebrew@gmail.com on 10 Jul 2010 at 5:28