OmniClient MessageTrans Error

With the 2016-04-09 or 2016-04-10 OMAP3 install (ZeroPain) I’m getting a SWI &41506 returned a bad error pointer when I click on a pre-defined mount in Omniclient.

&41506 MessageTrans_ErrorLookup suggests a problem with the Messages file does it not?

Ignore the error and supply the username/password for the mount and it works.

&41506 MessageTrans_ErrorLookup suggests a problem with the Messages file does it not?

Possibly a problem with the error block which was being supplied to MsgTrans for tokenisation – e.g. bad error number but a valid message token (otherwise MsgTrans would have returned the “token not found” error)

There is a password on the share that is being mounted but I deliberately don’t save the password in the mounts file. I always expect the username / password window to pop up as well as a warning message

This should be fixed with LanMan 2.55 – the code was passing in a bogus error number to MsgTrans and then trying to replace it with the real error number afterwards (if MsgTrans didn’t return an error itself). Except in this case the kernel was stepping in and causing a different error to be returned from MsgTrans.

There didn’t seem to be any real reason for doing things that way, so I’ve fixed LanMan (and several other modules which also had the same code) to just put the correct error number in the buffer that’s supplied to MsgTrans as input and forget about having to patch it in afterwards. However I get the feeling there might be more code that does similar things, so perhaps XMessageTrans_ErrorLookup should also go on the kernel’s ignore list (which would be a shame, because if MsgTrans does gain a bug it would make it harder to detect)

However I get the feeling there might be more code that does similar things, so perhaps XMessageTrans_ErrorLookup should also go on the kernel’s ignore list (which would be a shame, because if MsgTrans does gain a bug it would make it harder to detect)

I’m inclined to go with the easy detection of a larger number of bugs. I was reading the ADFFS info the other day and Johns zeropage fix list is starting to give war & peace a run for it’s money.
The thing is these things were crawling around in dark corners before.

A bit more searching revealed that the NVRAM module had a fairly valid reason for passing a bad error number in – it uses one of the reserved bits as a flag so it knows whether it needs to translate the error block or not. Changing that would involve making a temporary copy of the block on the stack (original may be in ROM), so to maintain compatibility with that (and to avoid breaking any other code out there) I’ve admitted defeat and gone with the safe option of having the kernel ignore bad error numbers from XMessageTrans_ErrorLookup.

In future if we suspect something fishy’s going on with MessageTrans then it’s only 4 lines of code which need deleting to restore the old behaviour, so this shouldn’t be a major problem when it comes to finding bugs.