SpotLess debugger

@alfkil

Noted two very small things:
- Uniconify generate a debug output, maybe need to be removed
- In about window there is a glitch in the copyright symbol

@Alfkil
Quote:

What i mean, that if we have visual garbage, then it mean we trash the memory somewhere, which, can cause all sort of side effects. Of course it understand that you want to fix it somehow later, but imho if we have trashing => we do have memory trash => unstable whole thing. It can't be that we have trashing somewhere visually, and this can wait :) Imho any visual trash = whole unstability of app. IMHO of course.

Quote:

Well, why this one seems gone (At least can't reproduce from 10 tries), but found now another issue (probabaly was here before too):

if i start spotless from the shell, load up test binary, hit breakpoint, hit start, hit again start to finish it up, and then close the spotless, i have in the shell:

***Command 'spotless' returned with hanging Disable!


Quote:

I not insist about of course, but again, IMHO debugger is important thing, and there should be everything perfect. As when we have something there, something there, icon default, no guide, etc,etc , then it feels like not finished. But that IMHO of course :)


Quote:

Did you tried with latest version ? Are you sure ? For me it have bunch of issues:

1. after loading and hit "start" it didn't starts. Instead bring some pause of everything, and then nothing.

2. something bad happens after progress bar is finished. Everything freezes for about 10 seconds. Nothing can be done, no mouse cursor moved, nothing. Like you do forbid() or something dunno , but something hardcore.

I made a video to show the problem:

https://youtu.be/iwc5LnNyIBo

See there how it:

00:08 - there progress bar arise, on the moment of loading mouse also can't be moved. Like whole aos4 take all resourses for.

00:10 - Progress bar end. Now you should see everything, but not. Since that and till 00:22 (so 12 seconds) we have a hardcore pause, when notihng works. Mouse can be moved, nothing works at all. Then, after those 12 seconds we have resoures back, and after few seconds it seems to show up the name of files used for build.

So main problem here : strange hardcore pause and nothing works. For quite long time.

And second problem, see at 00:30. I hit start. Nothing changes. Again hit start, again nothing. But spotless should start. So that seems to be second issue there.



And, 3st problem:

-- run spotless
-- load up spotless inside of spotless
-- wait while all this "freeze" gone (15-20 second in summary)
-- hit "start" => nothing happens
-- hit close gadget to exit.

Now after you do so, nothing can be clicked by mouse in the OS4, workbench is seems to be working, but mouse clicks did not. You can't run anything.

My IMHO, is that when we load up spotless inside of spotless we have some bad issues. Some trashing happens or something. Because of that we can't click after on anytihng, and spotless didn't starts. IMHO.

Quote:

I just mean if we want GUI be self explained, then as it now, is not understanable (at least for me :) ). For what we need that conigure ? What we configure there, and why we need to do so ? At least if no GUI change, we need a guide where explain what is it , and for what. As GUI itself not self-explained there. But, that IMHO of course :)

Quote:

If you feel it's hard enough then no big deal. I just see the snapshot functionality being added to lot of the later projects we have. Just by default window is too small, and you always need to resize it on every click. While of course can be tasty to made of size you preffered and save it. and in place you need it.

But of course, we better to deal with core funcionality first, as it seems still have issues. It imho should just load any binary, and when load it not have "Freezes" of everything, and when it exit after it should not kill aos4 functionality :)


Quote:

This one indeed not a big deal. It's enough as it is now, just for TODO or something. Or can be ignored completely, not big deal.

ps. And samo right, when we do iconify, we have always window output with "RA_Iconify" words in it. Like some debug left over which need to be removed.

@samo79

Quote:

Noted.

Quote:

I *know* about this, and the only solution I have found is to transfer the sourcefile to the Amiga, open it in notepad, delete the stray character and retransfer to the pc. I have done this before, but I always end up having to modify something and reverting the change.

Is there maybe a mistake in the character set on the Amiga side?

@kas1e

Quote:

This is a kernel issue. It should be fixed. Are you sure, your kernel is the latest beta?

About issues with loading and running Spotless inside Spotless : There must be some random issue responsible for the working on my side but not on yours. My best guess is - you guessed it - searching for leaks in reads from unknown memory territory. I have asked for help, and also the coming days I will brush over the code. Hope we can solve this. It is pretty cool to have a self-debugging debugger. :)

@Alfkil
Quote:

Yes. I tested on 54.48, and on the very latest 54.53. Just try it yourself, exactly steps to reproduce:

-- newcli
-- cd to spotless dir
-- type "spotless"
-- load any test case, run it, or not run, does not matter
-- hit close gadget = > hanging Disable error.

On what version you test ?

I just tested the version you send me today, maybe it's some new issue ?

@alfkil

For the Amiga side you may try NoWinEd to mantain the encoding

@alfkil

Quote:Well, only that AmigaOS does not support Unicode/UTF8, which you probably use (by default) in your editor on the PC. You could try (if your editor supports it) switching to ANSI for at least that source file before saving it.

Or avoid using the copyright symbol and replace it with e.g. (C).

(All assuming I am correct in guessing that the extra character is part of a UTF-8 sequence.)

Best regards,

Niels

@kas1e

Quote:

I see what you mean. This behavior is caused by the fact, that running through the entire list of source files is a heavy operation. Spotless needs to go into all the subitems of type N_SOL, which is a nested item type, and it needs to check for dublicates all the way though. Otherwise it would be insanely confusing to the user to have the same include files mentioned more than once. So with large binaries, it will take a lot of time and horsepower, and there is no real way around it.

The only thing, I can do, is to implement the "lazy load" functionality, that we actually had in db101. But remember, in db101 you were not able to access include files in the main code browser. This means, that even with "lazy load", there would still be a lot of overhead. And it is a bit more tricky to do with the current implementation, so I am going to save it for a time, where I have lots of time and confidence. For now, please live with the fact, that everything works as it should, even if it seems a bit "tough" with the heavy overload on this operation.

Also, I am not able to do a progress bar on the gui update, since it is a singular memory operation.

@alfkil
The problem with the loading, is that in all the years i use amigaos, i never see any app which on loading anything stop everything, even dockies, even mouse pointer ! Just completely freeze.

Yeah, whole loading of binaries with -gstabs very slow , but most problematic part is the total freeze without any output in. It's all in all x5000 with 2GHZ cpu, how it needs to load anything to the debugger, which take 12 seconds of total OS freeze ?:)

And Spotless binary is how much ? Just 8 megabytes ! And it can't cope with loading it acceptable and didn't freeze whole OS for that long ? I am sure there something very unusual done to make OS behave like this. It just feels like some bad things happens which trash memory, and that why binary then can't start.


Quote:

But you can't say that the unability to run spotless after i load it up with all those problems , are works as should ?:) It should run after, right ? Even if loading is slow, but correct one, binary should runs.

My bet, that there for sure some problem in. For you it works, maybe because you may load the spotless inside of spotless on partiion where you have indeed all your source code of spotless. And your parse see it, and behave correctly.

Ok, let forget Spotless. Take an db101 from os4depot, it have -gstabs inside. Then load it inside of spotless : the same freeze ! But it just 1megabyte binary ! And you can't the same run it !

Mayvbe this "strange slow loading" its because your -gstabs parse try to find your source files which paths you have inside of spotless binary, and procedure of checking them just fail badly, and bring us those issues with speed loading, and unablity to run Spotless.

So, to summorize : there for sure bug to fix. Not the "slow work" , but bug to fix. Any big enoug binary we load in spotless, cause a massive freezes, and then, you _can't_ start this binary.

Can you plz check it yourself ? Just try to download db101 from os4depot, and load up it in current Spotless from os4depot : you will see that you can't start it.

Ok for very slow loading and freezes, ok. We can live with it for now. But we can't after this loading run a binary. Even with slow -freeze loading, binary should starts. If it not, then there bug. And this strange "freezes" very much looks like some problem causing in end binary to not runs, and trash everyhting.

@nbache

Thanks, Niels! I knew, I could count on you. :) I have just changed the character to (c) for the time being.

@kas1e

Quote:

See, that's the funny thing : It works completely here!

I think there might be something wrong with some of the beta versions of intuition items (gadget classes etc.). When I do these tests here, they work. And I am not so sure how to fix it, when I cannot reproduce the behavior on my own system.

Maybe you have the option of starting up a system partition with plain Final Edition CD version? It could be nice to see, if we can pinpoint the version of the system, where this problem starts. Remember to update only the kernel on this system, if you have it.

@alfkil
Quote:

You mean you just download db101, then load it up into spotless, and then, after some "Freeze", you click "start" and it starts ?

Also, do you have db101 sources in the place db101 -gstabs point on ? Or you have it also as me - just list of sources which you don't have ?

Quote:

Just to be 100% sure: you test exactly version of spotless from os4depot (redownloaded) , and you test exactly today ? I mean to be 100% sure we don't talk about days ago when you do those tests, etc.


Quote:

What kernel do you use ? We talks before about "hanging Disable!" , which you were sure fixed in beta kernel, but i did try with 54.48 and on the very latest 54.53 : the same and always reproducable.

Quote:

I can setup just some test partition where install os4fe + update2 , and just add on top a kernel. But it still looks very strange that i always can reproduce those issues. I mean not random, just all the time.

Which kernel you use btw, release, or debug one ? Do you have "munge" added in os4_bootcommand so to have better bug-catch features ?

@kas1e

Damn. It doesn't work now. It worked yesterday, but I must have done some changes that breaks it. Oh well, further investigations!

@alfkil

Quote:

The easiest way would be to to open a console using a DOS open function with a CON window specifier. For example Open() a mode old file with name of:
"CON:////Spotless Output/AUTO/CLOSE/WAIT/SCREEN Spotless"

You can then pass the handle to SelectOutput() for DOS functions. Or if using printf() redirect it with freopen() and the C output handle.

You can also open a window and use the address. But it looks kind of hacky being able to use a low level pointer from the CLI. Fine from inside a program.

https://wiki.amigaos.net/wiki/AmigaDOS_Device_Input_and_Output#CON:

@Hypex

Thanks! I will save this and take a closer look, once I get the more pressing issues out of the way.

@kas1e

I have done some further testing of the self-loading case.

Spotless inside Spotless : There was an issue with a crash in the Pipe class. If removing reference to Pipe, I can now again load Spotless into Spotless and run it with no problems.

db101 inside Spotless : This seems to also be related to the pipe! I don't have a working repository for the db101 codebase, so I cannot change anything. But I am guessing, that there is some kind of mess with the parent/child relation between the processes, that makes the calls to the queue-handler fail.

So for both : There is a real crash, and they are both related to pipe. If references to pipe is removed, they should both work again.

@alfkil
That good !

Through then big question : why it works for you before when you test the same version as me ? :)

And reference to pipe where ? Inside of programms we load in, or that spotless do things bad ? If inside of programms, then it mean every programm with reference to pipe will crash ?:)

@kas1e

Quote:

That is a good question! I have to say, that I simply don't know, since I cannot reproduce. Maybe it was just a freak accident or a lucky punch. :)

@Alfkil
Quote:

Or, what is more possible : you use self-build-modified kernel for tests, mean no luck to be the same as me in tests, because your builds of kernel will simple shift the memory regions or / and allocate something differently and violla - going in circles when one have a bug, and another one not. And that not because you change anything in kernel at all, but because you may use another compiler, another flags, and build or debug or release kernel and things always will differently.

To be the same we need to test things on the same kerneles, byte in byte.

And to say truth i didn't understand stuff about pipe :) Is it issues inside of spotless, or did you say that if programm with reference to pipe is loaded, then it will not works ? I just didn't understand part about needs to change anything in db101 : db101 works fine as before, and if i remember right i can load db101 inside of db101: it's spotless which bring us such issues for now and which we tried to fix. Or i just dumb enough and not understand all that stuff about pipe ?:)

@kas1e

Quote:

See this : PIPE: issue on Hyperion Forum

The reference to PIPE: is from within the Pipe class in Spotless. This class is meant to be used to pipe output from the child to the parent. If it worked, then the output of the child would be shown in the Console window inside Spotless. But it doesn't work, due to some issue with buffered io in Newlib.

The reason for the crash : I simply don't know. Only thing I can say is, that if I comment out the line responsible for creating the Pipe class instance, then the problem goes away. And of course : Because this only happens when the application is loaded as a child of another process, then it must be caused by either something with the parent/child relation or by other details in the call to CreateNewProcTags().

By the way : You should revert your elf.library to 53.27. The new one causes total system freeze on all these issues. The only reason, that I can know about the solution (pipe), is because I can see the stacktrace both inside Spotless and inside the GR.