@msteed
Quote:

I switched to IPC only because I started losing strings (some had garbage when they shouldn't). Maybe it was a side effect of a bug or something else, but once I began copying strings and tags in the patch and sending them via messages, the bug disappeared. But of course, this means I now have more code to handle, like first copying, then parsing, and overall it’s starting to be a bit too much, but still probably safer...

Quote:

Yes, for copying strings and tags, I use AllocVecTags, and currently my GenericPatch function and SendIPCMessage function look like this:

Patching function:




SendIPCMessage():



And then, after I copy it all, I have to reparse and print it, so it's like double the work...

But for now I'm facing another problem: 64-bit arguments for some dos.library functions. The issue is:

Currently, all my patching code, wrappers for functions, etc., are using uint32/int32. That's everywhere, and all arguments are treated like this too (bytes, words, etc., are treated as longs, so int32, no problems there; strings and pointers fit into int32 as well). But then, dos.library has six functions that allow some arguments to be int64:




Now, if I patch those functions with my generic patch, which expects all arguments to be int32, I'll just get bugs because an int64 takes up two int32 slots, causing memory shifts, crashes, and other issues. I see that I need to handle int64 as two int32s in all cases, but that means changing GenericPatch, SendIPCMessage, and the logger to always skip two int32s when encountering an int64, and it’s starting to feel like a mess.

If I change everything in the code (wrappers, GenericPatch, etc.) to use int64, I’ll run into problems with int32 arguments for the same reasons.

So, for now, I’m thinking about how to solve this one...

@kas1e

Quote:
I've been thinking about this, and since no one else has jumped in, here are my thoughts.

Typically, your current approach -- doing as little as possible in the patch, and postponing the formatting and output to Snork itself -- is the recommended way to handle such things. But I wonder if in this case your original approach -- doing everything, including the DebugPrintF(), in the patch -- isn't a better idea.

One drawback to the current approach is that logging the function call is asynchronous to the function call itself- by the time Snork gets the message and outputs the log, the call has already occurred. So if the call crashes due to a bad argument, the crash occurs before the call can be logged (and if the crash takes down the system, the log will never be written).

A bigger problem comes up when you start logging exec.library calls. I presume you allocate memory in the patch to hold all the copies of arguments, and memory allocation can break a Forbid() that might be in effect when Exec is called. It looks like that can be prevented by using the AVT_Wait, FALSE tag with AllocVecTags().

An even bigger problem is that some exec.library calls may be made from interrupts, and memory allocation can't be done from within an interrupt. (I'd guess that TypeOfMem() isn't safe to use from an interrupt, either.)

Calling DebugPrintF() from within the patch eliminates both of those problems, while also making the logging synchronous to the function calls. And there's no need to copy anything except strings (where you're also filtering out unprintable characters), and those could be buffered on the stack (though you're using the caller's stack, so you have to be careful how much you use).

As far as I'm aware, there's no public information on the internal workings of DebugPrintF(). But given its intended purpose, I'd speculate that it depends as little as possible on the rest of the system (and presumably is okay to use from within an interrupt), and likely writes directly to the serial port (in SERIAL mode) with no buffering, and so doesn't return until the entire string has been sent.

If this is in fact the case it will be slow (especially when logging a tag list), as it takes 87 us for every character written at 115.2 kbps (it should be much faster if writing to the debug buffer or if using Sashimi). But the advantages of doing it this way may outweigh the reduced speed.

@daveyw

Okay, it's winter where you are, but here in Switzerland, we're baked!

He might have caught a cold

My fan is a Gelid Silent 6.

@daveyw

Thermal paste dries over years. I would clean old away ant put new good quality thermal paste there.

@skynet

5020. I've had it since 2017.

I live in the Southern Hemisphere, its winter right now, although my office is reasonably pleasant temperature, but certainly nowhere near 31! Probably not quite 20.

Yeah, 76 does sound high. Maybe because of your high room temperature? Do you know which fan you have? I have the Gelid Silence that most of the X5000s from Amigakit shipped with.

Hi daveyw,

Which model do you have, 5020 or 5040?

I've had a 5040 for a year now.

Out of curiosity and in relation to your problem, I checked my processor temperature and it's at 76 degrees Celsius.

I still find it high for my CPU.

I don't really have any idea why your problem is happening; maybe it's due to the heat?

I currently have 31 degrees in my office with a small fan and all the windows open, but no air.

I hope it's nothing serious.

@Maijestro

ok. that's another thing. D&D on AmiDock works if program has ReadArgs() IIRC it's working on.

I was work on a project on Friday, not run anything too demanding, when suddenly I noticed a CPU temperature alert. CPU was running 98 degrees!

I powered off and let it cool for a while, then unplugged everything and powered it up lying on its side with the case open to check the CPU fan. It seemed fine.

Plugged everything back in and switched on again. Uboot came up, but OS wouldn't boot. The splash screen sloooowly faded up and then froze.

Left it to cool even longer, then tried again. This time it booted, although again there was the very slow fade up on the splash screen. CPU temperature slowly rose to 58 degrees. I did a backup and powered off.

According to the CPU temp docky, CPU fan speed is 30%. Is there any way to increase this?

@kas1e

Quote:

Sorry, I expressed myself incorrectly, I meant Drag&Drop via AmiDock which does not yet work with the latest version 0.3.

@Maijestro
D&D were added in v0.2, check release notes :)
And yeah, i working on, just not ready for next beta

@Maijestro

you can try yourself on the beta/demo:
https://kas1e.mikendezign.com/aos4/dumbpad/v03/dumbpad_v03.lha

@kas1e

I'm not sure if I may have missed it, but did you already have drag and drop support added to DumpPad?

Hopefully you will continue to work on this great editor.

@trixie
I enjoyed reading your article. And I agree with the majority of what you wrote and the way of thinking.

But, this is the best approach for developers and people who want to dive deeper in the OS. For plain users, and we have observed that happening, the whole situation seems frustrating and they leave the community. There is a need to keep a healthy and productive environment for people to feel that things are moving forward. I just hope that the number of people who would care about the survival and expandability of the platform will increase every year.

@trixie
Quote:

That's how I think for years, keeping me away from being disappointed by anything. We use what we already have, and if there are updates - cool, if not, I know what I do and with what. Waiting for anything from leaders or hoping for any promises is the way to the trap. Let them do what they think and can do, but it shouldn't reflect on you in any case.

@johnfante

yep, there still some issues, 'cos server(s) where updated.
Hope they will fixed ASAP.

@joerg
Quote:

Good catch , thanks !

Btw, what is the best way to follow if we need to parse data in a patch ? At fist, i just doing simple parsing inside of the patch, and then print it before calling original function. Then after , i add some simple IPC via PutMsg() (from patch) /GetMsg() (in main).

At first i tried to simple send what i have to the main, but find out that strings and other data simple died offten (because patch is done, memory changes, but i tried to handle it in the main which is point on whatever else). Because of that i had to copy in the patch before putmsg whole set : libname, functionname, doing findtaks(null), copy strings and tags, and then send this instead. For copy i use IExec->CopyMem/IUtility->Strlcpy (that for libname, funcname and strings), and for tags i simple do simple loop copy.

The question i had now , is it correct way of doing things. I mean, for speed and for being correct at all. As i doing dynamic copy for each patching function, i do not need locks and mutexes, but not sure shouldn't i somehow protect it or not ?

@jabirulo

Thank you! That is the version I am running.

Think this is some kind of server error.

@johnfante

there is an update AmiUpdate v2.56:
http://www.codebench.co.uk/amiupdate_ ... /index.php?page=downloads

Think it fixes the amissl v5 issue.

@msteed
Quote:Some functions may work with invalid string pointers, depending on other arguments the string pointer may not be used at all by the function itself and if it isn't accessed there wont be a DSI.
But Snork would cause a DSI trying to print it.

@kas1e
Quote:= strlcpy(output, "NULL", output_size);

strncpy() and strncat() should be replaced by strlcpy() and strlcat().

Quote:Replace by to add support for international chars, for example the default ISO 8859-15 ones.
Unprintable control chars on AmigaOS, in any supported 8 bit charset, are only 0-31 and 127-159.