ROOL Forum: Recent Posts

Thu, 13 Aug 2020 23:45:29 -0000

As you may have noticed over on The Icon Bar the London Show will be going virtual this year. Exactly what form this will take has still to be decided – we will probably have a better idea after next week’s ROUGOL meeting. I will make a proper announcement once things are clearer.

Thu, 13 Aug 2020 23:13:12 -0000

You also need to bear in mind that softloadable copies of modules typically won’t be binary identical to ROM versions. There are lots of ways in which the two can differ (different code generation from the compiler/assembler due to different CPU type targets, dynamic registration of files with ResourceFS, different versions of the C library stubs for ROM vs. softload, etc.)

So although the softload version places the crash site in malloc, in reality it may have been in one of the functions near malloc in the binary.

Thu, 13 Aug 2020 23:03:35 -0000

Learn all about Cloverleaf from Stefan at the next online ROUGOL meeting on Monday 17th August 2020. Details here – https://www.riscosopen.org/forum/forums/1/topics/15523

Thu, 13 Aug 2020 22:58:31 -0000

The next meeting of the RISC OS User Group Of London (online) is:

Cloverleaf and ChatCube, presented by Stefan Fröhling

Monday 17th August 2020, 7.45pm

Online via Zoom, meeting open from 7.30pm

http://www.rougol.jellybaby.net/meetings/

This month we are delighted to have Stefan Fröhling joining us all the way from Thailand to tell us all about the Cloverleaf project and give a demo of their first product, the instant messenger program ChatCube.

Set up just over a year ago, Cloverleaf’s primary goal is a crowdfunding campaign to raise funds to develop those applications that are missing from the RISC OS portfolio, as well as updating the OS where required.

They also aim to release a series of machines based around the Rockchip RK3399 processor, featuring a 2GHz ARM A72 core which would make them the fastest RISC OS systems available. The machines will range from an entry level mini system up to an all in one desktop and a laptop.

Alongside the Zoom discussions we will also have chat going on in the ChatCube, so why not download it beforehand and join the meeting from RISC OS too!

This meeting will be held online via Zoom. Please contact us to receive a link to the meeting on the day.

http://www.rougol.jellybaby.net/contacts/

Thu, 13 Aug 2020 22:36:47 -0000

There’s now a new test build of Clipper out, which is available here

It works around clipboard owners which don’t like null type lists in their Message_DataRequests, which previously denied Clipper access to their data. In addition, following feedback on csa.apps, an Adjust-click on Clipper’s iconbar icon will insert the current clipboard contents at the caret (assuming that the clipboard owner can supply it in plain text format).

Thu, 13 Aug 2020 22:32:22 -0000

Since the clipboard’s content is likely to be in RAM, wouldn’t it make sense for the data exchange to be by RAM transfer?

Sort of, although there’s quite a lot of stuff that doesn’t do RAM Transfer (there was some issue with WimpScrap exchanges in the early Clipboard Manager code that caused it to fail, IIRC, which caused all kinds of wild speculation over on the R-Comp mailing list). I had initially planned to upgrade Clipper to do RAM Transfer, until I looked at how it’s implemented.

It’s not really an option for Clipper, because of how it works. Since it allows the user to drag the clipboard contents to disc, all that it actually does is lie enough to both the clipboard owner and the destination task (the filer, or whatever) such that both parties believe that they’re actually talking to each other, then lets them get on with it. This allows it to do something apparently complex with very little code. Given all of the MyRef/YourRef tracking that goes on to make it all work, it’s also a good example of how to do the protocols completely (and it’s in BASIC, too).

For now, I’ve worked around the issue by following the null list with one specifying “text” if the original message either bounces or goes into a black hole. I’ve also dropped David P an email; I’m assuming that this thread should be sufficient to get some feedback about the Clipboard Manager…

Thu, 13 Aug 2020 21:37:29 -0000

I think that means it crashed in malloc(). If it was actually a bug in malloc() I think we’d have bigger problems than occasional crashes in Paint. There aren’t many places that Paint itself calls malloc(). With brush selection it gets used to build a palette and hold translation tables. Of course it could also be a RISC_OSLib function that called it or the WIMP.

Thu, 13 Aug 2020 20:28:14 -0000

any ideas on where the problem lies

I have no experience whatsoever of programming for the Clipboard, so this is a totally naive idea…

Since the clipboard’s content is likely to be in RAM, wouldn’t it make sense for the data exchange to be by RAM transfer? Maybe it uses that and doesn’t even bother to implement a file-based protocol.

Thu, 13 Aug 2020 19:26:10 -0000

And how does one do that? https://shadowcrypt.net/tools/cloudflare tells me that 104.22.41.215 is protected by Cloudflare,

Ah, working with suppliers that use cloudflare and knowing from them the backdoor. I wanted to test and eliminate the cloudflare element since everyone was blaming internal “network” issues (as ever) and I wanted to test the whole chain via NHS net and also on a direct Internet connection.
I replicated the flakey behaviour on the direct and removed it when given direct access to the actual server.

Thu, 13 Aug 2020 17:45:28 -0000

Wow, OK. I did look at _primitive_alloc() because it was one of only a couple of places in RISC_OSLib with “+ 4096” but I didn’t think the logic exactly matched up. I guess it got optimised.

Thu, 13 Aug 2020 17:30:06 -0000

The trouble is, there’s nothing obvious in that to identify what that routine is. No SWI calls, and I can’t find one routine in the sources that obviously uses most of those constants in the same sort of place.

The clues are there, they’re just hidden! Look at

20243B30 : E3A02006 : .  ã : MOV     R2,#6
20243B34 : E3A01003 : .. ã : MOV     R1,#3
20243B38 : E3A00033 : 3. ã : MOV     R0,#&33
20243B3C : EB0047B3 : ³G.ë : BL      &20255A10

Once you know that you’ll find the macro ACQUIREMUTEX which is only used in 3 places, and only _primitive_alloc() makes sense given the rest of the disassembly you gave.