UniPrint / UniServer crash on Pi2

I’m using UniPrint on my very old rPi 1 – and it works great. Using it on a fresh installation on my rPi 2 – it prints one document, but instead of showing the ‘success’ window, it crashes.

Does anybody else have the same experience? Or a different one?

The same here on Pi3

Since it worked on the rPi2 (v1.1) before, I put in the old rPi1 image (RISC OS RC14) and it works – no problem.
So, whatever it is, it has to do with the RC15 image (which is needed for the rPi3 and rPi2 v1.2).

I’ll reflash the SD card with a RC14 image and see how it goes. Putting the old RC14 image on the RC15 flashed SD card does not do the trick. Since I am new to RISC OS, I just assume it is something you cannot simply do. ;)

I can confirm a rPi2 v1.1 is OK with the UniServer and RISC RC14. The whole rPi2 v1.1 is not running too stable, though, so I switched back to my rPi1. Overclocking the rPi1 to 1200MHz does not make a huge speed difference to the rPi2 v1.1 . And interestingly, this is running more stable with RC14. For now I’m a happy camper, but would love to see the bug removed at some point. ;)

Further testing: disabling the Popup notification windows does prevent the crash and the software can be used further.

Also, the current bleeding edge RISC OS ROM with the Zero Pain patch applied prevents the crash from happening. So, the problem seems to be solved in the next release of RISC OS. I’ll stay with RISC OS RC14 on the rPi2 v1.1, until the new release is coming out.

Also, the current bleeding edge RISC OS ROM with the Zero Pain patch applied prevents the crash from happening.

The zeropain module will have produced a diagnostic log.
That log needs to be sent to the support address for uniprint with the information about the machine and OS version in use.

got it, will send it :) Thanks for the advise, did not know it creates log files ….

did not know it creates log files

That’s actually a major part of it’s function. Basically zeropain is required on “high-vector” OS builds¹ and zeropain “catches” the errors resulting from attempts to directly access zero page locations stopping the error from causing an application crash and it logs data pointing to the likely cause. There’s a page in the wiki that everyone ought to read and update if they find a zeropage error. Uniprint/Uniserver is not currently listed.

The more people try every application or tool they have and report the errors then the more the whole system becomes a stable environment. A number of software authors have actually stated that fixing these specific identified items have removed niggly ‘sometimes it just does this’ errors that they could never quite pin down.

¹ Older OS builds were allowing dodgy code to carry on with unpredictable results – it may never have shown a problem then again all those “sometimes application A crashes like this” could actually be application B (or even a bit of the OS) having done something it shouldn’t some time before.

I believe this has now been resolved, pending a confirmation from Rob.