Memory protection and tasks/processes

@afxgroup

Quote:

this should be

Quote:

if do not set pointer to NULL then “if (pointer)” is useless.

I see lots of init code, exit at first failure, and so do not set other pointers later in functions, so you have none initialized pointers, it’s extremely typical.

Some tools to find bugs, will actually suggest you should remove “if (pointer)”, because 99% of time does not crash the OS and program, only 1% of time it takes down the OS, but it considered a bug because slows down the program, crazy, I guess Linux people do not care anymore, because the OS can handle almost anything.

@NinjaCyborg

Yes, your sandbox idea is pretty god, but it has one major problem, and it is that you need wrap a hell of a lot of functions, but it has some advantages, you can add resource tracking to the sandbox, it can also provide chipset support, and it can interact with native program to a degree.

It reminds me of vamos project,

https://lallafa.de/blog/amiga-projects/amitools/vamos/

there is also the janus-UAE project, tried to do something similar.

I think idea was not bad, but it needs a lot more work.

Not just some simple patches.

@LiveForIt

I don't deny it's a lot of work. But if they are rewriting Workbench anyway for OS4 it might have made sense to do it back then. After all, they have spend 20 years so I think it's not more work than the way they actually did it.

Most OS operate with a window server, window server process owns the windows and controls, application just 'rents' them. In this way one well tested and well written component can take the big responsibility away from apps developers. Why Workbench instead of Intuition though? Because workbench is single place that knows about all kinds of resources, files, icons, windows, processes, ports, devices, whilst intuition is only one subset of that.

@LiveForIt

Yes, NULL is after the free. This doesn't change the sense of the question. for example this piece of code in clib2:



where __delete_semaphore is a simply:



is crashing in the kernel with a DSI and freeze the entire OS. Is this normal? Keep in mind that some software for other platforms (in the specific VLC), when use free() will not check neither if the pointer is null or not. Yes. is a bad pratice but in the case that pointer is null the OS will not be erased with it.

@afxgroup

If this discussion is literally about free(NULL), then it shouldn't be doing anything:

https://github.com/adtools/clib2/blob/ ... ibrary/stdlib_free.c#L586

@afxgroup

is crashing in the kernel with a DSI and freeze the entire OS. Is this normal?

YES..


anyway this looks like nonsense.
“Delete” is not the same as “Release”
Delete is like free or delete object,
while release in this context is unclocking the dirent_lock, so another task can use it, at least on (Windows and AmigaOS)

If the code looks like:



in this case you don’t know if you lock or not.

You have case like

O = Obtain
R = Release
W = write
r = Read
F = Free mem
A = Alloc Mem
. = time tick.

0 ms time -------- > Lots of ms Time


Task1 ....O..wwww.R............O..rrr.F.....A.wwwwwww.R.
Task2 ..............O...www...R......R.................
Task3 .................................O..rrrr..R.....


in this case Task3 thinks it can read but because there is a bug, its released the lock twice in task2.
Task3 will read freed/corrupted data, and crash with DSI.

Or you can have cases where…
Task1 ….. O ….. O [freeez] [then crash…]

Task1 freeze becouse Semaphore is already obtained.

way it crashes is, because the message port gets new messages that is never replyed, and so never deleted, so message port fills up until system crashes. (most likely)

or/and the sender maybe locks up becouse it waiting to replay.

@Capehill

No unlucky is FreePooled that is crashing in the Kernel. Most probably for the same ReleaseSemaphore problem.
Is not the C lib is crashing otherwise it will be simply to fix.
The problem is that the kernel is causing a DSI and is hard to track it down

And however the problem is not different tasks are trying to access the semaphore. Is the same task that is calling FreeSysObject on a VALID semaphore that is causing a DSI into kernel.
And for me a DSI in a system component is not so normal as you said. At least it should protected by bad code. I've also printed some test lines:

CLIB_CONSTRUCTOR: dirent_lock = 0x5e4b4160 - TASK = 0x5fdc5510
__dirent_lock = 0x5e4b4160 - TASK = 0x5fdc5510
__dirent_unlock = 0x5e4b4160 - TASK = 0x5fdc5510
__dirent_lock = 0x5e4b4160 - TASK = 0x5fdc5510
__dirent_unlock = 0x5e4b4160 - TASK = 0x5fdc5510
__dirent_lock = 0x5e4b4160 - TASK = 0x5fdc5510
__dirent_unlock = 0x5e4b4160 - TASK = 0x5fdc5510
__dirent_lock = 0x5e4b4160 - TASK = 0x5fdc5510
__dirent_unlock = 0x5e4b4160 - TASK = 0x5fdc5510
semaphore1 = 0x5b4acd20 - 0x5fdc5510
semaphore2 = 0x5b4acd20 - 0x5fdc5510
semaphore3 = 0x00000000 - 0x5fdc5510
semaphore1 = 0x5b4acd50 - 0x5fdc5510
semaphore2 = 0x5b4acd50 - 0x5fdc5510
semaphore3 = 0x00000000 - 0x5fdc5510

CLIB_DESTRUCTOR = 0x5e4b4160 - TASK = 0x5fdc5510
semaphore1 = 0x5e4b4160 - 0x5fdc5510
semaphore2 = 0x5e4b4160 - 0x5fdc5510

In the CLIB_CONSTRUCTOR is created the dirent lock and used without any problem (see lock/unlock) operations.

semapore1/2/3 are taken from



and so that function is workin correctly and as you can see the semaphore is set to NULL correctly.
in CLIB_DESTRUCTOR is called the same funcion that crash in FreeSysObject. And the Semaphore is not locked so is not the problem.
So where is the problem?

@afxgroup


No idea if this is relevant but setting semaphore to NULL only affects the local copy of the semaphore variable in that function won't it? So if you're using the semaphore elsewhere in your program after calling this it will have been freed and won't be NULL. If you want it to be reflected elsewhere in the program, you'd need to pass in a struct SignalSemaphore **sem variable and set *sem to NULL.

yes. it could be. But that __delete_semaphore function is called only in the CLIB_DESTRUCTOR with that pointer. no one is using or calling it because it is the constructor/destructor of dirent funcion and indeed after __delete_semaphore there is also the NULL of the pointer

__delete_semaphore(dirent_lock);
dirent_lock = NULL;

Basically, the constuctor create the semaphore object and the desctructor free it

I've also tried to use ASO_NoTrack to see if something change but is the same

@afxgroup

Ok do you want to paste the contructor and usage code to see if anything can be spotted? Do your number of calls to ObtainSemaphore (), ObtainSemaphoreShared () and AttemptSemaphore () match the number of ReleaseSemaphore() calls? Is it a public Semaphore? If so, is there a call to RemSemaphore () before the CLIB_DESTRUCTOR? I'm just trying to think of possible causes off the top of my head?

well i've found the problem

if I use



it crash. But if i use



it works.. now. where is the problem? Is the pointer paged out? when? from who..

@afxgroup

Is that a paste error? Do you mean



The other thing is the other example is a struct variable on the stack so it must be different code compared to your AllocSysObject () code returning a pointer, yeah? I'm assuming since the stack-based code is in a single function, could you show us the code in that function for both scenarios?

Yes. It was just a code example.

@afxgroup

Without a complete and minimalistic example, people just keep on making random guesses.

EDIT:



Works for me.

x

The problem is not in FreeSysObject itself. The problem is somewhere in some cases i cannot reproduce with a small example. But i've fixed the problem usin InitSemaphore instead of using AllocSysObject. So what is the difference between this two kind of allocating a semaphore? Now i have the same exact crash in expunge function of pthread. and there is a semaphore also there.
So, yes it could be my code. but this means that also pthreads.library has a problem? i don't think so.
There is something within gcc10+so+clib2 that is causing "sometimes" this problem
i've also tried an example that use libc.som plus pthread.so and no crash at all.. so there is something that is causing this issue.