Quote:

When I'm developing, I can usually crash and then kill stuff several times before having to reboot...

You're a lucky boy When I'm developing, if my application popup a GR, at the 90% of cases, if I click on Kill, this one freeze the system, If I click on Ignore DSI then CPU goes to 100% of usage...

Quote:

You're a lucky boy When I'm developing, if my application popup a GR, at the 90% of cases, if I click on Kill, this one freeze the system, If I click on Ignore DSI then CPU goes to 100% of usage...

The first case is very odd, because when the Grim Reaper appears, the task is already frozen. If the system still works, it should still continue working if you kill the task in most cases. It works pretty much every time here.

"Ignore DSI" is not magic. It entirely depends on what the application does or was trying to do. If it was reading in a loop looking for a particular piece of data, but reading from an invalid address, it'll never get that data and loop forever. Nothing anyone could do about it.

As for all the calls to close windows of killed tasks, there is no way to know which task is responsible for which window. You could guess, but it would just be a guess, and that could be more dangerous than leaving it alone.

_________________
Playstation Network ID: xeron6

Quote:

I am a bit disappointed to see some one sided bashing from someone I thought would be above that

What's wrong with this statement? I recently had installed a program on Windows that came with its own copy protection. From that point on, every time I right-clicked on an icon I get an explorer crash. I don't have the slightest idea why and what to do about it (the proposed fix does not work for me), so I am about to re-install Windows.

On the Amiga, I would know where to look. That's what I said, and sadly it is true. This is not about being better or worse. It is about KNOWING your system, about TRANSPARENCY to the user. That's all I said.

_________________
Seriously, if you want to contact me do not bother sending me a PM here. Write me a mail

Quote:

Why not add a checkmark "Remove related data such as windows and files" when killing a task?! How oven does one task open a window and let another task draw in it vs. how many times a task opens its own window and draws in it and then crash??!

Resource tracking is actually in AmigaOS 4.0 already, but it doesn't work like that on AmigaOS. There are programs that actually terminate and assume that their resources stay in memory, and as long as this is the case, things can't go that route.

Quote:

Think about it: What is most dangerous: Remove a task and its windows, risking that another task is drawing into it. Or removing a task and leave the window putting intuition into a sure crash and deadlock of the system.

How many other tasks actually draw into windows? Unless you open a window with a shared message port, you cannot handle its IntuiMessages from another task anyway since the signal is allocated by your task.

And no, just because there is a window will not put Intuition into a deadlock. You can test this by opening a window and immediately exiting. Nothing will happen.

_________________
Seriously, if you want to contact me do not bother sending me a PM here. Write me a mail

Quote:

So, the sentence used by HJF means that the average Amigan knows where to search for a problem in his system and how to actually solve it. Shake your Amiga

Don't laugh. Way back in the early years (late 1980's) a friend of mine brought his Amiga 500 to the shop for repair. The guy at the shop looked at it, held it half a meter over the table, and dropped it. Then he plugged it in, and it worked again.

True story. Apparently they did that frequently when parts on the PCB had come lose.

_________________
Seriously, if you want to contact me do not bother sending me a PM here. Write me a mail

Quote:

Anyone of OS4 team would explain us why is not there anything of similar? :)

On AmigaOS there is no direct relation between resources and task. It's not like in Windows or UNIX where e.g. memory is directly mapped into an address space. Resources are just that, resources, and a lot of people in the past did freely pass them around between tasks.

In the case of windows, Deniil715 complaints that things will crash if you leave another task to draw into the window. But, what exactly will happen when you close the window? There is no way that another task will know that there is a stale pointer; it will assume that the window is still there, and crash as well. So, leaving the window open has a much bigger chance of not crashing than closing it.

Again, as long as there is no strict division between private and public resources on AmigaOS, this is how it has to stay.

_________________
Seriously, if you want to contact me do not bother sending me a PM here. Write me a mail

Quote:

If I click on Ignore DSI then CPU goes to 100% of usage...

If you chose to ignore a DSI, you're running a much greater risk of damaging something than if you just kill the task. A DSI is an error, period. What you get from reading or writing to a non-mapped address is garbage at best, and you are continuing on the assumption that this garbage has a meaning. Most likely, though, any calculation done with garbage will result in garbage again (the GIGO principle - garbage in, garbage out).

Ignoring DSI's that have been, for example, caused by trying to clear a megabyte of non-mapped memory will result in a million follow-up DSI's, and believe me, that will take a while. It might result in an endless loop as well. Anything can happen.

Bottom line is, if your program DSI's, kill it. Reboot afterward when you have saved everything you need. Everything else is risky.

And, I'd like to point out, any instabilities are the result of faulty programs, not the OS.

_________________
Seriously, if you want to contact me do not bother sending me a PM here. Write me a mail

@Rogue:

Quote:

Don't laugh. Way back in the early years (late 1980's) a friend of mine brought his Amiga 500 to the shop for repair. The guy at the shop looked at it, held it half a meter over the table, and dropped it. Then he plugged it in, and it worked again. True story. Apparently they did that frequently when parts on the PCB had come lose.

Hehe, yes, this way of "repair" was possibly invented by AtariST dealers (there is a rumour about Sinclair dealers/repair centers doing the same trick earlier), because the first series had serious problems with the chip sockets. I saw some doing that trick myself. Later on they used some clamps to fix the chips in their sockets (and some repair centers even used a plastic hammer to reseat the chips first!) and Atari used that for later series, too.

But I still can´t believe that shaking will do the trick for e.g. filesystem problems on Amiga

Thank god, such problems could be solved quite easy for AmigaOS (every incarnation of it), just as you said.

Regards

Quote:

And no, just because there is a window will not put Intuition into a deadlock. You can test this by opening a window and immediately exiting. Nothing will happen

When the user clicks into the window or types on the keyboard or in other cases Intuition may want to send IntuiMessage to the window's task. If the task is dead this can cause all kind of problems/crashes/deadlock, whatever. If you start program from a shell, then this may not become immediately visible, as the program is running inside shell task which does not go away if you terminate program. Until you close shell.

Also some window attributes may "live" in app task/space/program segment, like likely the window title. Or user gadgets, menus. And if those disappears this causes trouble, too.

"demand-based paging": what if some memory needs to be paged in while Forbid() state is active (for example ObtainSemaphore() is called and the semaphore struct memory is in memory which was paged out earlier) or while some DOS locks are held?

@Rogue
Quote:

I don't have the slightest idea why and what to do about it (the proposed fix does not work for me), so I am about to re-install Windows.

That only means that you are not very familiar with Windows and that you know AmigaOS better. Not very surprising, considering your background, is it? But I don't see how any conclusions about transparency can be drawn from that.

Last edited by ara on 21-Aug-2008 at 12:47 PM.

@Rogue

Quote:

In the case of windows, Deniil715 complaints that things will crash if you leave another task to draw into the window. But, what exactly will happen when you close the window? There is no way that another task will know that there is a stale pointer; it will assume that the window is still there, and crash as well. So, leaving the window open has a much bigger chance of not crashing than closing it.

You're not getting my point here!

I know that if another task is writing onto a window that gets closed, it sure will crash. But the point is that this situation is very uncommon compared to the normal case where the same task that opened and take signals from a window is also the only one using it. But because of this I suggested the checkmark.

I also would like to see the GDB button moved into the More window, and instead put a Suspend button in the first window.

Why leaving a window open will crash intuition (and hence freeze the system since the GR needs intuition) is because the window title is part of the task that got killed and removed, so when the window border is redrawn dure to window movement or in/activation, intuition will reference a deallocated string and crash.

On Classic this was visible as garbage in the window title instead, but the system lived on because it lacked MP. (No, I'm not opting for removal of MP, of course.)

_________________
- Don't get fooled by my avatar, I'm not like that (anymore, mostly... maybe only sometimes)
> Amiga Classic and OS4 developer for OnyxSoft.

Quote:

Again, as long as there is no strict division between private and public resources on AmigaOS, this is how it has to stay.

Question is: when will you introduce that notion ? The sooner, the better...

Yes, this may mean losing compatibility: so what ? I guess it's *high* time the OS gets improved... We won't stay in the past, will we ? The faster compatibilty is dropped, applications taking advantage of it can be written...

_________________
http://www.warpdesign.fr/

Quote:

When the user clicks into the window or types on the keyboard or in other cases Intuition may want to send IntuiMessage to the window's task. If the task is dead this can cause all kind of problems/crashes/deadlock, whatever. If you start program from a shell, then this may not become immediately visible, as the program is running inside shell task which does not go away if you terminate program. Until you close shell.

Intuition doesn't send anything to the window's task. It sends something to the window's message port. If that is a shared port, yes, there might be a problem. If it isn't, and it's a private port, then there is likely no problem. There is no telling whether removing a window is safer or not - both can be true.

_________________
Seriously, if you want to contact me do not bother sending me a PM here. Write me a mail

Quote:

"demand-based paging": what if some memory needs to be paged in while Forbid() state is active (for example ObtainSemaphore() is called and the semaphore struct memory is in memory which was paged out earlier) or while some DOS locks are held?

Semaphores and any memory that needs to be accessed in interrupts or Forbid state needs to be allocated as shared memory, which is not swapped.

DOS Locks are irrelevant since the swapping is done to a dedicated partition, not a file.

_________________
Seriously, if you want to contact me do not bother sending me a PM here. Write me a mail

Quote:

That only means that you are not very familiar with Windows and that you know AmigaOS better. Not very surprising, considering your background, is it? But I don't see how any conclusions about transparency can be drawn from that.

I consider myself a knowledgeable user, and if I, as a developer (who also did do Windows development) do not know what to do, an average user won't know either.

_________________
Seriously, if you want to contact me do not bother sending me a PM here. Write me a mail

Quote:

I know that if another task is writing onto a window that gets closed, it sure will crash

Strangely enough, this is exactly the opposite of what you said in your first post.

Quote:

But the point is that this situation is very uncommon compared to the normal case where the same task that opened and take signals from a window is also the only one using it.

Yes. It's very bold, though, to leave such a choice to a user. How would you know that this will actually be the case or not, without being the developer?

Quote:

Why leaving a window open will crash intuition (and hence freeze the system since the GR needs intuition) is because the window title is part of the task that got killed and removed, so when the window border is redrawn dure to window movement or in/activation, intuition will reference a deallocated string and crash.

Actually, no. The task stays in memory. You cannot predict what other task might have resources shared with this one, and removing it would be a danger. As I said before, when a program has crashed, the only sensible way to proceed is to save all work and reboot.

_________________
Seriously, if you want to contact me do not bother sending me a PM here. Write me a mail

Quote:

I consider myself a knowledgeable user, and if I, as a developer (who also did do Windows development) do not know what to do, an average user won't know either.

Hehe, surely it is common knowledge by now: "Reinstall the whole OS"

Anyway, any errors in NoelFuellers translation?

_________________
Site admins are people too..pooff!

Quote:

ntuition doesn't send anything to the window's task. It sends something to the window's message port.

Which almost always is of type PA_SIGNAL so the msgport signal is sent to the mp_SigTask task. This sets task.tc_SigRecvd, etc.

If a killed task and it's Task struct is not removed from memory and a Signal() also doesn't possibly bring it back out of zombie/dead state it might be ok.

Quote:

Semaphores and any memory that needs to be accessed in interrupts or Forbid state needs to be allocated as shared memory, which is not swapped.

And existing apps do follow this rules? Does malloc() return shared memory?