SpotLess tests need it to find out one bug

@All
Alfkil release a first usable public version of SpotLess debugger here:

https://drive.google.com/file/d/1vv9kX ... Du-uhjW/view?usp=drivesdk


So far all fine, but there are issue i found on my x5000, which Alfkil can't reproduce. Will be very nice if some of you can reproduce it (so it will mean issue not on my own setup).

What you need to do:

-- download spotless debugger on link below. unpack it to work:debug/spotless/ (that need to mimic fully my settings)
-- 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 from the shell
-- 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 , 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 issues, but then, click "start" button again. This time you will be definately have crash/deadlock.

That is reproducable on my x5000 all the time, always with 100% reproduce.

If some of you can try it on their hardware , that will be very helpfull for us.

Thanks!

@kas1e
I tested it and unfortunately crashes on my X5000 as well
Here is the crash log I got at the serial
https://os4coding.net/node/2499

@george
Good ! Mean that not my machine.

Interesting, that if you remove "munge" from command line option of kernel, then bug survive first bad memory usage, but then hitting second time crash will again crash, even without "munge" being set.

With "munge" we just faster catch the crash, just as there no stacktrace, etc we don't know wtf.. And alfkil by some reassons can't reproduce on his x5000 (through, he not have "munge" enabled, while should, of course:) munge is a lot of help).

I run the test 3-4 times and unfortunately I couldn't get more info at the serial port. Always the same results.

@kas1e
on my SAM460ex your exec crashed too here.
Recompiled using
Using built-in specs.
COLLECT_GCC=/PRUEBAS/SDK/gcc/ppc-amigaos/bin/11.2.0/gcc
COLLECT_LTO_WRAPPER=/PRUEBAS/SDK/gcc/ppc-amigaos/bin/11.2.0/../libexec/gcc/ppc-amigaos/11.2.0/lto-wrapper
Target: ppc-amigaos
Configured with: /opt/adtools/gcc/repo/configure --with-bugurl=https://github.com/sba1/adtools/issues --with-pkgversion='adtools build 11.2.0' --host=ppc-amigaos --target=ppc-amigaos --disable-nls --prefix=/gcc --with-gmp=/opt/adtools/native-build/root-cross --with-mpfr=/opt/adtools/native-build/root-cross --with-mpc=/opt/adtools/native-build/root-cross --program-prefix=ppc-amigaos- --program-suffix=-11 --libexecdir=/gcc/libexec --enable-languages=c,c++ --enable-haifa --enable-sjlj-exceptions --disable-libstdcxx-pch --disable-tls --enable-threads=amigaos --enable-lto --disable-c++tools
Thread model: amigaos
Supported LTO compression algorithms: zlib
gcc version 11.2.0 (adtools build 11.2.0)
#
#gcc test.c -lauto -gstabs -o test


and then Spotless worked fine.

http://jabirulo.byethost13.com/temp/test.7z

<joke>Or if you want I can swap my SAM460ex with your X5000 so test work fine </joke>

@Javier
Quote:

Ha .. intersting !

That the exe i got from Alfkil when we start to test things.

Strange he can't reproduce issue, maybe he just rebuild exe somehow different (as you now), and the one he send me was "buggy" ? Or maybe it was build with different options / different compiler ?

Through does not matter how binary were done, it should't crash of course.

@kas1e

did a few more test and here it makes system unstable too.
Recomnpiled (#gcc test.c -o test -gstabs) and works fine.

Can you try with my build (or just recompile it yourself) I attached earlier and see if it works on your system?

@walkero

Since the stacktraces says dos.library and SmartFileSystem, it could be some disk access problem. I have a hard time guessing the problem, but I know, that the only disk access from spotless in this case would be reading and updating from code text files (test.c in this case). Does this give you a hint?

@alfkil
I saw the same thing, but that's what I get at the serial. Possible something crashes that hard that brings down the smartfilesystem, which crashes afterwards?

What I will try is to test the same process. in different filesystems and see what I get at the serial.

Will let you know when I have the results.

@Alfkil,Walkero
My partitions are NGFS, not SFS ones as some of you have, so that not it.

Also, it's quite common to have crash in kickstarts handling that or that, when crash is heavy one.

@kas1e

Ok. I will add some more serial writeouts, when I get back from the hospital. Hopefully we can figure out, where the crash happens.

Fresh version updloaded (same link). Please report back, if it still crashes and if you get something new on the serial. Hopefully we can track something.

@alfkil
Quote:

By this-same link says that you delete it :)

@kas1e

New link

My X5000 died again.

what happens??

@afxgroup

I had to go to the hospital with a bad lung. And I forgot to cut the power. So it had been on for 6 days non-stop, and probably som circuitry overheated.

Any news on the latest version?

@Alfkil
I do test it yesterday, and have mixed results. For first test, it's the same as before crashes, so after that i connect serial cable to catch a crash, and it stop crashes.

I will test futher, but maybe lot of prinfs on serial now make "deadlock" gone ?

@George, Javier

Can you confirm that with new version crash seems to be harder to reproduce ?

@kas1e

I did use with deficons sources/code and a few breakpoints and worked flawlessly: