Page 1 of 1

Can't install daily build past 2018-08-08

Posted: Sun Aug 19, 2018 1:02 am
by pepijn
I am not sure if it's a bug or I'm doing someting wrong but if I try any new build after 08 of august it just craches.

The error is: "An error has occurred in the following application.
Saved Core File Succeeded."

here is the psp2dmp(from psp2-master-aaf3aeeb) not sure if it will help:

Exception Prefetch abort exception
Thread ID 0x40010003
Thread name VSCU00001
EPC 0x01019B74
Cause 0x00030003
BadVAddr 0x00000000
a1: 0x82980F9C a2: 0x00000000 a3: 0x0000004C a4: 0xDEADBEEF
v1: 0xDEADBEEF v2: 0xDEADBEEF v3: 0x82980FE8 v4: 0x00000000
v5: 0x00000000 v6: 0xDEADBEEF v7: 0xDEADBEEF v8: 0xDEADBEEF
ip: 0xDEADBEEF sp: 0x82980F98 lr: 0x81052D87 pc: 0x01019B74

Posted: Sun Aug 19, 2018 11:27 am
by digitall
Hmm, not sure, but there are no PSP related changes to backend code around that date. However, it was the date that the new Startrek engine was merged into the tree.

I have checked and the PSP build is monolithic, so wonder if we are hitting a memory limit since the EBOOT.BIN inside the VPK is now 15M...

One solution would be to disable the startrek engine for now and see if the build is usable again. If so, we will need to look at multiple builds for different engines and/or plugins for engines on PSP (and by we, I meant the PSP porters).

Posted: Mon Aug 20, 2018 12:39 pm
by digitall
Ah sorry. Minor braino on my part, but PS Vita uses the psp2 backend which is a variant of the SDL platform backend i.e. it is based on SDL.

However, my previous conclusions still stand i.e. there are no changes to the backends around 8th August so this is most likely due to addition of Startrek engine and thus size increase in binary.

Will add code to the buildbot to disable the startrek engine for PS Vita.

pepijn: Can you test with the next nightly build and see if this now works again?

Posted: Mon Aug 20, 2018 12:51 pm
by digitall
AHA ... So this has been an issue before. Will restore the hack or similar to get the binaries working again. ... 6902500d66 ... f8a4d97fb0 ... 8ec93eda73

Posted: Mon Aug 20, 2018 3:07 pm
by rsn8887
Yes, -Os optimization removed the need for the hack, but startrek might have pushed it over the edge again.

I think the star trek engine is already playable. Maybe other, unplayable engines should be disabled instead?

Posted: Mon Aug 20, 2018 6:47 pm
by digitall
rsn8887: Well, we first need to see if disabling the Startrek engine fixes the issue for now. After that, we can switch around as per your 8ab80a3eec27e545bc5d607d7877bc6902500d66 commit to disable unplayable engines... I don't think you can do --disable-unstable-engines as that covers all the engines still in WIP like Startrek which it would be useful to compile test at least.

Is there any way to detect the "too large binary" issue at compile time or by running a tool from the SDK on the binary produced? So we can detect the condition and fail the build in those cases? i.e. maybe objdump or similar to give segment statistics with a bit of shell in make rule to check..

As I said before, the real final solution would be to implement plugin loading (--enable-plugins --default-dynamic passed to configure) as per PSP i.e. ... n_Portable

Posted: Mon Aug 20, 2018 11:43 pm
by pepijn
digitall wrote: pepijn: Can you test with the next nightly build and see if this now works again?
thx works for now again :D