Presentations

Setup

• Find the Forum post that reported it.
• Have a CLib and BASIC module in the working directory so that we can use them if we need to.
• Have a copy of the PRM to hand, at the start page.

Script

Have the forum post open https://riscosopen.org/forum/forums/4/topics/17616

In this video I'm going to show how you can use RISC OS Pyromaniac to investigate a problem with a module. I'm going to re-visit an old bug that I diagnosed last year, and show the steps I went through to get there.

The problem was reported in the RISC OS Open forums. The RISC OS Open Resolver module was broken in some way. The reporter believed that there was something up with hosts being looked up case sensitively, or not at all. This is the forum post that they originally reported it with, and someone helpfully gave a link to the changelog. We're going to start from there and see what we can find.

git clone ...ResolverBlob
git checkout <sha>
ls

Explain that we've got some modules that we'll probably need, and that it has checked out the sources.

cd ResolverBlob
ls aof

I remember this is a partially linked module that we need to link to make a module.

riscos-link -rmf aof/ResolverSA C:o.stubsG -o resolver,ffa

There are missing resources... they must be built, I guess. Check the makefile for what the resources are?

They join the files together and then run resgen on the results.

cat Resources/UK/Messages Resources/UK/CmdHelp > JoinedMessages
riscos-resgen -apcs 3/32/nonreent/fp/swst Resources aof/resources JoinedMessages Resources.Resolver.Messages
riscos-link -rmf aof/resources aof/ResolverSA C:o.stubsG -o resolver,ffa

pyrodev --load-module ../CLib,ffa --config memorymap.zeropage_enable=true --load-module resolver,ffa --command gos

Ok, so it's loaded... how do we test this

*Help resolver

You cannot check the status of the system using GetHost as it's not built in... so we'll call the SWI ourselves. But that needs BASIC - not installed here.

pyrodev --load-module ../CLib,ffa --config memorymap.zeropage_enable=true --load-module resolver,ffa --load-module ../BASIC,ffa --command gos

*BASIC

Look up the Resolver_GetHostByName in the PRM

SYS "Resolver_GetHostByName",,"localhost" TO err, hostent

Generates a weird error... probably because it didn't realise that its messages file couldn't be opened. That's not what we're looking for here as a bug. It should still be able to read the hosts file.

Oh, but hang on, we don't have a hosts file.

*Show Inet*

Resolver uses InetDbase:Hosts to read the hosts file, and that system variable isn't set. And we don't have a hosts file anyhow. So let's make one.

*Edit Hosts
127.0.0.1<tab>localhost
ctrl-x to save

*Set InetDbase$Path $.
*type InetDBase:Hosts

Let's do a resolverconfig. I'm not sure if it's required, but it's meant to reconfigure the module.

*ResolverConfig

And try again...

SYS "Resolver_GetHostByName",,"localhost" TO err, hostent

Still that odd error. Ok, let's look up what E02 is.

*Type JoinedMessages

Ok so it's complaining with E02 that it's not configured. The other messages are the values of the parameters but there are no %0 to %3 in the message so they're not used. Let's configure it then...

*Set Inet$Resolvers 1.2.3.4
*ResolverConfig

And try again...

SYS "Resolver_GetHostByName",,"localhost" TO err, hostent

It's hung. Ok, Press ctrl-c. I assume that means that it's going to the network to try to resolve things... which might be a symptom of what the reporter was saying.

Let's see what file operations are being performed - if it's not read the file properly, we might be able to see that. Let's list the debug and find a filesystem debug we can use.

*pyromaniacdebug

Scrolling up to the filesystem ones, let's enable osfile and osfilestream - osfile is the plain OS_File calls, and osfilestream relates to all the file handle operations from OS_Find onwards.

I'll restart Resolver as it might have cached the failed localhost lookup.

*RMReinit Resolver

Oh Hang on ... that's not right - it's trying to find the file '/etc/hosts'.

SYS "Resolver_GetHostByName",,"localhost" TO err, hostent

Yup, that's trying to read the file /etc/hosts rather than InetDbase:Hosts.

That's where we're going wrong. The issue with the case might be due to something else, but the bigger problem is that it isn't even using the right hosts file