@Alfkil Did i understand right what you say : i need to rollback to elf.library 53.27, so PIPE issue will gone ? Or reverting to 53.27 need because of some other bugs ?
@rjd324 This is just the same old GDB we have in few different recompilations, which have the same sort of all problems. Mean of no use as crashy and buggy. On x5000 there were issues with kernel some time ago, but then they were fixed, and gdb start to "kind of works" again on x5000, but the same crashy and buggy. From my side there was some attept to hire some programmers outside to made a proper port, but they all fail, as once the realise amount of work they all retired.
@alfkil Got the new version you send me on mail : i can now run spotless inside of spotless without crash now, but if i load up db101 inside of spotless, then i have GR (which i can ignore) in Process.cpp:180.
Then the bug with "returned with hanging Disable" still here : it's enough to start spotless and then load up any simple test case, run it , and exit from spotless , and as result : "returned with hanging Disable!"
And the most important and problematic part : welcome to our previous bug with crash on my test case ! Here is again :) Damn. Exactly the same bug :
-- download this test case: https://kas1e.mikendezign.com/aos4/debug/spotless/test.tar and unpack it to "work:debug/spotless/" as it. So you will have test case binary/source and .txt file in the "work:debug/spotless/spotless-test".
-- run Spotless -- hit "load" button -- choose in the "spotless-test" directory a file "test" -- when it loads up , you will see name "test.c" on the left side, click on it to show the source. -- in source file, click on the line 30 to set breakpoint on it. -- hit START.
At this point , you crash. Sometime you may have crash with GR, sometime you may have crash without GR (just on serial), but whole GUI will be deadlocked. Sometime you will have no crash at all, but then, click "start" button again. This time you will be definately have crash/deadlock.
So , all of this mean that that something really wrong with all this. Everything fucked up with strange bugs :) and we don't know what/where/why. Every version only shift issues in one, or another side, but then another version shift it back and same issues happens again and again. It looks like problem always there, just shifts depends on the size of the code... meaning shiftin of memory regions and allocated memory, which in turn mean trashing of memory somewhere cause all this.
At least for a start, we need to remove trashing of memory in "Variables", it's just point out that something already trashed in memory, who know how and where it manifest.
To summorize what we have with newer version you send me:
1). spotless inside of spotless runs 2). db101 inside of spotless crashes on running, but ignore dsi helps 3). crash-freeze bug with my test case again back.
ps. Plz, test all on the same as me : latest beta kernel, no custom made kernels, so you can reproduce everything yourself too.
Everything fucked up with strange bugs :) and we don't know what/where/why
You are wrong. I know quite well where to track these problems. One is with elf.library and the other is with the PIPE:. I bet I could solve both of these, if I had code access.
You are wrong. I know quite well where to track these problems. One is with elf.library and the other is with the PIPE:. I bet I could solve both of these, if I had code access.
Wait wait, i am lost :) We don't have just 2 bugs about missing stack trace and crash. We have MORE bugs. At least for now 3 is very visibly. And i don't mean now missing stack traces or trashed variables fields.
I was under impression, that the last version you send me for test that you do remove reference to PIPE: ? but then, loading db101 into spotless still crashes. Then it's not problem with PIP ? I mean If reference to PIPE were removed, but loading db101 to spotless still crashes, then it's not PIPE issue, right ?:)
And bug about hanging disable when runnig spotless in a shell, you say it fixed in beta kernel, but i checked - no, bug still here. Was you able to reproduce it now ? And if yeas, that is issue with PIPE ? Or you mean that is issue with elf.library ? I am lost, sorry :)
Probabaly my english too bad, but i will try another time to explain what issues we have:
1). Loading db101 inside of Spotless cause GR in process.cpp:180 That with version of spotless with removed reference to PIPE which you send me last.
2). If you run spotless from the shell, load any simple test case to it, and then exit, you have "you exit with hanging Disable!".
3). Load my test case as i explain, hit BP on line 30, hit start => crash with total trashing of memory all over the places. Usually lockup with trash on serial, sometime just GR with no stack trace.
Now, you say that elf.library need fixing and PIPE need to be fixed. But then , it will deal with what ? With crash when we load db101 inside of spotless ? With "hanging Disable!" on exit ? With crash when i simple try to trace my simple test case ?:)
Quote:
I bet I could solve both of these, if I had code access.
That only 2 issues, and for one you already removed reference to pipe, no? And second one is about missing stack trace , right ? But that all not about crash when we tried to trace with my test case which again there, and not about "hanging Disable!" on exit when running from shell and not about db101 crash when load inside of spotless (as i test it with removed reference to Pipe).
We have then 5 bugs insdead.
PS. Btw, maybe we better use github's ticket for bugs ? By this i can create all the reports, and you can see what one and when deal with for real and it will be just much better to trace it all, if you of course doesn't mind and still wish to spend your time on.
1) This is caused by db101 opening the pipe. It is the same issue as in Spotless, only I have not removed the reference to PIPE: inside db101. So it is still that same issue.
2) You are right, this is an issue also. I'm very unsure how to fix this, and I am pretty sure, that someone else would have a better chance of fixing it than me.
3) This is caused be the problem with CloseElfTags().
What other issues are you thinking of? I can only count these three. And then of course the garbled output in the Context pane. But that is for later.
BTW : The "freeze", that you describe in your video is probably due to copying operations inside libstdc++. There is no way, I can fix this.
EDIT : The "garbled output" from Context is actually not so insane. It is merely caused by the fact, that the variables are uninitialized. There is a safety on the memory read operation, so it should not crash. And there is no way to tell, if a variable has been initialized, so the relevant functions will just print whatever values, the particular (uninitialized) variables are pointing to.
1) This is caused by db101 opening the pipe. It is the same issue as in Spotless, only I have not removed the reference to PIPE: inside db101. So it is still that same issue.
Hm, i just tried to run db101 alone, without Spotless, and it runs ok, without crashes. But when i run it inside of spotless (with removed pipe) it still crash.
Quote:
2) You are right, this is an issue also. I'm very unsure how to fix this, and I am pretty sure, that someone else would have a better chance of fixing it than me.
I am sure kernel guys will fix it, if we will provide them with minimalistic test case. This one also will help for us to see if issue actually a kernel, on on our side. Because if we will say them "spotless on exit bring issue about Disable!", they will ask for minimal test case, as they will not dig in into spotless to find if it fault of app or of a kernel.
Quote:
3) This is caused be the problem with CloseElfTags().
Imho, as in the other case we need to provide a minimalistic test case showing the problem, then it have chances to be fixed. Because if we will say that "CloseElfTags() broken", they will for sure fix nothing :)
Quote:
What other issues are you thinking of? I can only count these three. And then of course the garbled output in the Context pane. But that is for later.
I am thinking firstly about garbled output in variable yes, and then, also non-working stack trace.
Quote:
BTW : The "freeze", that you describe in your video is probably due to copying operations inside libstdc++. There is no way, I can fix this.
Are you sure about ? I mean, i didn't see any other amigaos application which when do copy freeze the whole OS and take so much time for copy.
Maybe you can made a test case showing actual problem ? We have much more harder apps which use a lot of copy in all the ways, and they never freeze everything and mouse pointer as well. Maybe you just do "forbid()" before and then permit() after ? That can explain such a hardcore freeze.
What spotless need to copy, so to load up a 7mb binary take 12 seconds of total os freeze ? Some big tables ? Or much more than 7mb ? Maybe this is set of small copies, and for each you "open" shared library or something ? There should be something which can explain wtf is wrong with. Maybe if we can understand what exactly cause this problem and provide a simple test case, someone may fix it..
Btw, sorry i forgot what was the reasson that we need to supply with spotless this libstdc++.so and use .so at all ? I see spotless didn't use sobjes at all
Quote:
EDIT : The "garbled output" from Context is actually not so insane. It is merely caused by the fact, that the variables are uninitialized. There is a safety on the memory read operation, so it should not crash. And there is no way to tell, if a variable has been initialized, so the relevant functions will just print whatever values, the particular (uninitialized) variables are pointing to.
Sounds bad yeah if we can't put instead of trash something like empty spaces or word "none"..
Anyway, IMHO, we need to create test cases for the bugs you mentioned and then we can be sure that its not our fault, and annoy exec team to fix it :)
From my side i can happyly help with any tests of those test cases and co
Hm, i just tried to run db101 alone, without Spotless, and it runs ok, without crashes. But when i run it inside of spotless (with removed pipe) it still crash.
You misunderstand. It is the child, that crashes, and it happens because the child is opening the pipe. When the child is run outside Spotless, there is no crash. I have done a test, replacing the to Open("PIPE:") with Open("dymmy.txt"), and this prevents the crash.
Quote:
I am sure kernel guys will fix it, if we will provide them with minimalistic test case. This one also will help for us to see if issue actually a kernel, on on our side. Because if we will say them "spotless on exit bring issue about Disable!", they will ask for minimal test case, as they will not dig in into spotless to find if it fault of app or of a kernel.
This is difficult, though. I am not sure, I would be able to pinpoint, what stuff needs to be isolated to cause the bug in a minimal setting. I think it is better to use Spotless as the test case and providing debug output from inside a custom kernel.
Quote:
Imho, as in the other case we need to provide a minimalistic test case showing the problem, then it have chances to be fixed. Because if we will say that "CloseElfTags() broken", they will for sure fix nothing :)
Again, it is a complicated case, and maybe the complexity is required for the bug to appear. I think better to use Spotless as a testcase and provide instructions for reproducing the bug.
Quote:
I am thinking firstly about garbled output in variable yes, and then, also non-working stack trace.
The stacktrace works. It has just been disabled in the public version. And there is a crash, yes, but the basic functionality is sound.
Quote:
Are you sure about ? I mean, i didn't see any other amigaos application which when do copy freeze the whole OS and take so much time for copy.
I have browsed the sources again and again, and I see no reason for the stall other than some kind of block on large copy operations from c++ vectors and lists.
Quote:
Sounds bad yeah if we can't put instead of trash something like empty spaces or word "none"..
As I said : This is not possible. The only way to tell, if a variable value is legit is to test, if that memory area is readable. And I am already doing that.
Again, it is a complicated case, and maybe the complexity is required for the bug to appear. I think better to use Spotless as a testcase and provide instructions for reproducing the bug.
I fear if we will give Spotless as test case, no one will dig in much, as it always was with no-test case but application as test case :)
Quote:
I have browsed the sources again and again, and I see no reason for the stall other than some kind of block on large copy operations from c++ vectors and lists.
So the problem is in the c++ copy operations mixing vectors and lists ? Can we isolate this one at least so to know wtf ? I mean, of course you as author see no reassons with that stall , but maybe it worth to create test case at least for this one ? Just to understand from where problem comes and what involved and why it reacts like this.
Did i understand right, that you just copy there sizeof(binary) to some place and then take the info from this block, and that operation stalls on 12 second on x5000 when just parse 7mb block from memory ?
PS. Maybe it worth to try to build spotless with latest afxgroup's clib2 ? Just to see, if issues with copy will be there ?
So, what about this then? Does this command line version of gdb work fine on the X5000?
No, this predates the X5000 by a mile. It works on Classic and it should work on G3/G4 XE but I haven't confirmed that yet. For some reason I cut off the readme when I uploaded it.
So the problem is in the c++ copy operations mixing vectors and lists ?
It is not due to the mixing. It is due to the sheer size of the stabs section in the Spotless executable. There are literally tens of thousands of stabs, and because I am doing the lazy ass version of the code inside Spotless, then there will be several copy operations on complicated object hierarchies when doing the gui update.
I could go ahead and implement the lazy interpretation, that I mentioned before. But right now I would really like to fix this MUNGE bug.
I could go ahead and implement the lazy interpretation, that I mentioned before. But right now I would really like to fix this MUNGE bug.
If i understand right, just like it was in db101 ? db101 surely load spotless very fast. By fast i mean ULTRA fast. 1 second or something to load up whole spotless binary and show all the soure lines and and everything.
I just have in it:
New process loaded Interpreting stabs Loading module spotless Stabs setion relocated Module bounds (0xxxxxxxxx - 0xxxxxxxxx) then list of source files of spotless and some other stuff at that all.
For all that it takes for sure less than 1 second. Maybe 0.5 second. Or ok, just a second. Very very fast.
Is only because of that lazy interpretation ? Huge deal!
Even progress bar is veerrryy fast. Just like milliseconds, i even didn't have time to see it. But in Spotless, progress bar showsups, take a 2 seconds or something for loading, then 12 seconds waiting, then another progress bar, and only then.
If it can be as in db101, they yeah, that surely need it!
Quote:
By the way : clib2 version of Spotless performs the same as newlib version. At least here on my platform.
Btw, did you use original clib2, or the clib2 from Andrea ? Andrea's one was pretty much improved, have many fixed, additional stuff and co, so can make an impact too on.
But as we found in mails, seems problems wasnt newlib/clib2 absolutly ..
@All Some of you may have missed it, but there is a new version of Spotless on os4depot, where Alfkil adds a lot of new stuff. I do help him beta-test it as much as I can and taking all the shit out of it and we hope this is probably one of the most stable and well-tested ones, taking into account that it also provides developers with a list of new improvements, some of which are quite big!
There they are:
Quote:
Firstly, there several menu enhancements:
- Added a split window mode with the ability to show and hide individual windows.
- Additional windows, such as configuration and memory surfer windows, can now be selected from the RMB menu.
- Added code to reflect each case with additional windows: does not matter if chosen by RMB or buttons; the RMB menu reflects all the states in any mode, on the fly.
Then, there new features:
- When a break occurs, the source file name in the Sources panel is highlighted.
- Added auto-generated configurations for saving window sizes and positions across switches and restarting.
- Added the option to "Ask for arguments" or "Do not ask for arguments" when loading a binary.
- Reworked the disassembler window in split window mode to reduce the amount of empty space.
As well as numerous bug fixes:
- stacktrace (various fixes, including kas1e'e's "line 30" issue)
- iconify (proper window content refresh in all modes and conditions, removal of debug output)
- binary handling improvements (ability to run self, db101, and all binaries using external Amiga libraries).
- corrected a "long waiting bug" when parsing binary stabs.
- The main's stepinto (the tracer) is now fixed.
- Bugs in Memory Surfer were fixed (clean break points, assembly steps, etc.).
- The crash with relative paths has been resolved.
- improvements to overall stability and a lot of code cleaning work being done.
The only disadvantage of this release is that it requires the most recent kernel, which is not yet public and is in beta.
As a result, the developers most likely to benefit are those who have beta versions of the kernel (at least for x5000 for sure).
It may (or may not) work on older kernels, but at least on X5000, you will have bugs, crashes, and glitches with a public kernel.
It was also not tested on the X1000, Pegasos 2, Sam460 or the old Eytech Amigas, so it remains to be seen how they perform on those platforms (i hope to test it myself soon, just it wasn't done for this version).
As can be seen, a lot of work is being put into creating "gui" and all the other stuff in this version so that even those on public kernels can at least test the GUI and all other things that aren't directly related to debugging itself, and help to improve things by filing bug reports. I am of course trying to get a shit out of it and spam Alfkil with all kinds of issues, which he tirelessly fixes, but there surely can be something we miss.
See how looks like new "window split" mode (click on image for fullsize):
If Alkfil doesn't lose motivation (which I hope he doesn't), we'll have a decent (and first!) normal OS 4 debugger.
You can always show your support by donating to Alfkil's PayPal account : alfkil()gmail.com
Thanks also to the ExecSG team (this time Salas00 and Thomas) for fixing things in the kernel to make it work.
Edited by kas1e on 2022/11/18 15:48:14 Edited by kas1e on 2022/11/18 15:48:44 Edited by kas1e on 2022/11/18 15:50:14
Some of you may have missed it, but there is a new version of Spotless on os4depot
I have and X1000 and don't have the beta kernal but I would really like to see a nice debugger on OS4 and fully support Spotless development.
I did download the latest build and started it up to look at the GUI a bit. The one thing I noticed is on startup the first time it opened up a consol with the message, "Error reading prefs file from disk config.prefs. A new file will be created.". Two things. This isn't really an error so maybe it would be better to put of an info requester indicating it didn't find a prefs file so it's creating a new one. This info requester could have an auto timeout.
Error reading prefs file from disk config.prefs. A new file will be created.".
This is a good point. I didn't realize at the time of writing, that this message would be so confusing. I will definetely rethink it for the next release.
I didn't report this one just because for me is good to see that one have no config and new created.
Yeah, but ktadd's point is it shouldn't be saying that it was an error. It's a normal situation, so it should just be an informational message (if shown at all).
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
