printf() crashing PSP when used with kernel mode in 3.xx?

[Hellcat]

Yah, the bugger again

[action=Hellcat]has yet another problem....[/action]
Not uncommon theese days


OK, this is it:
First off, I'm in 3.xx kernel mode, no legacy 1.50.... (however, same crash on 1.50, I tried....)
I have this nice and shiny kernel .PRX that gave some headaches already.... so far it's loading fine and working.... somehow....

I have also setup a function in my (main) usermode .PRX that will handle some stuff (file IO) I can't do in the kernelmode .PRX due to 3.xx kernelmode restrictions.
So, the kernel .PRX calls the function in the user .PRX (I give the kernel .PRX the address of the function in the user .PRX at runtime - similar to like callbacks work - as a parameter to a function in the kernel .PRX that saves the pointer (to the user .PRX function) into a function definition/pointer....)
For debugging/testing, I am currently (trying) to printf() the filename and filesize instead of actually writing files.....

And that just kills the PSP O_O

It does a few printf's and crashes - boom.
If I comment out the printf() line, everthing runns smooth....

Is there a known issue with printing f's while kerneling in the backyard?



[action=Hellcat]hopes that one day good stuff will arise from so many q's....[/action]


Supplemental explanation to the weirdness described above:

In user .PRX I have:

int Blah(int bleh)
{
some code
}

int main(....)
{
....some code
kernelPrxFunctionToSavePo inter(&Blah);
....more code
}


In kernel .PRX:

// prototype
int Blah(int bleh);

// pointer
int (*Blah) (int bleh)

kernelPrxFunctionToSavePo inter(void* func)
{
Blah = func;
}

someRandomFunction(....)
{
Blah(1234);
}



Like said, the call to Blah() works fine, does everything it should, many, many, times, up to the end....
....as long as in Blah() are NO printf's, once those are in -> CRASHY

[Archaemic]

That's...unusual. Some code, please?

[Hellcat]

Just edited some more info into it....


I remember a very early DAX downgrader did also make no use of printf'ing the current file 'cause that caused the PSP to crash....

[bogalog]

Was that the original GTA downgrader where no text would be displayed, you just had to start it and wait?
Heh thats the one i used, I was so worried when it was running
Unfortunately I have no coding experience, so I am of no use in this thread, but I am glad to hear you are still working on the project Hellcat

[Art]

The prx printing all the fs might be in the middle of printing fs when it is told
to print other fs by the prx that decides what fs to print.
So a semaphore could be done with little overhead to tell the main routine to shutup and wait until it's ready.

shutup = 1;
print buffer full of fs
shutup = 0;

Now you can see if the print routine is printing fs
before annoying it by checking the status of shutup.
If you started overwriting the printf buffer with another part of the program while it was printing
it might not be good for programs that are supposed to keep running.

[Hellcat]

Good thinking.... but didn't do the trick....

But: I added a scePowerTick() at the start of the function that is supposed to do the file IO (and for testing only makes the printf's) - that seemed to have helped!
At least it now printed everything it should and the program returned without failure....

Hope this stays stable

[Mr305]

A very n00b thing that you might have missed may be, Did you try Kprintf?

[Hellcat]

Too bad, the power tick didn't help a thing, still crashing....

Originally Posted by Mr305

A very n00b thing that you might have missed may be, Did you try Kprintf?

O_O
Huh?

Anyway, it's also crashing when not doing any printf()....
Seems like 3.xx kernel really doesn't like calling functions from userspace.... (on 1.50 it starts beeing stable)

------------------------------------------

Ahhhrg... SCREW IT!
I liked the idea of directly calling a function in my usermodule SO much.... but 3.xx kernel really doesn't want that.
I'll change course now, handle it differently.... gotta get this sucker finished....