freemint-discuss — The official FreeMiNT Mailing List

Re: [Freemint-discuss] GDB 14.1 for PRG/ELF

[Eero T. <oa...@he...>]

Hi,

On 7.2.2024 23.12, Miro Kropáček wrote:
> Congratulations Vincent, you have again pulled this off. After all those
> attempts during the past years, we really have a modern GCC couple with a
> modern debugger.

That's a really great achievement, congratulations to everybody involved!


> The only thing I can add is a vague hope that some of the m68k
> inefficiencies will be fixed in near future:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113779. Thanks to Olivier for
> such a straight-forward and blatant example of gcc's inefficiency so it
> even woke up some gcc people. :)

Ok, so there are two really bad inefficiencies in GCC code generation, 
both related to straightforward copy operations (above one, and the one 
where fixed size e.g. struct copies are replaced with memcpy() calls, 
but never replaced on m68k by inline version in later optimization stages).


	- Eero

> On Wed, 7 Feb 2024 at 21:53, Vincent Rivière <vin...@fr...>
> wrote:
> 
>> Hi,
>>
>> Last August I announced GDB with PRG/ELF support. After that, we worked
>> hard
>> on GitHub with Thorsten Otto and Miro Kropáček to polish it.
>>
>> And finally, here it is:
>> http://vincent.riviere.free.fr/soft/m68k-atari-mintelf/archives/mint/gdb/
>>
>> I haven't much more to say. It just works.
>> Cross-compile your program with the mintelf toolchain and the -g option.
>> Copy the resulting executable and the sources to your MiNT machine, then
>> you
>> can use GDB to debug it, at source-level. All fancy stuff is available,
>> including breakpoints, display variable contents, disassembly. Even the
>> very
>> convenient TUI mode works like a charm in TosWin2 for full-screen
>> debugging.
>>
>> Important:
>> - ARAnyM-JIT is incompatible with GDB (it may hang). Use standard ARAnyM
>> (non-JIT) instead.
>> - GDB for ColdFire works well. But a bug with TRACE flag handling inside
>> BaS/FireTOS causes a whole system hang on resume after breakpoint. The fix
>> exists, but isn't available yet.
>> - GDB should work well on other targets, as long as you have enough RAM.
>>
>> Enjoy 😃
>>
>> Note:
>> For people not familiar with GDB, I've added a quickstart on the download
>> page with a few useful commands.
>>
>> --
>> Vincent Rivière
>>
>>
>> _______________________________________________
>> Freemint-discuss mailing list
>> Fre...@li...
>> https://lists.sourceforge.net/lists/listinfo/freemint-discuss
>>
> 
> 
> 
> 
> _______________________________________________
> Freemint-discuss mailing list
> Fre...@li...
> https://lists.sourceforge.net/lists/listinfo/freemint-discuss

Re: [Freemint-discuss] GDB 14.1 for PRG/ELF

[Peter S. <ps...@sc...>]

Hi,

That's great news.  I must confess the first and last time I used gdb
was when I was dabbling with Highwire in about 2008.

I am getting more into freepascal so I am hoping they can get it to
work with gdb as well.



Peter



On Wed, 2024-02-07 at 22:12 +0100, Miro Kropáček wrote:
> Congratulations Vincent, you have again pulled this off. After all
> those attempts during the past years, we really have a modern GCC
> couple with a modern debugger.
> 
> The only thing I can add is a vague hope that some of the m68k
> inefficiencies will be fixed in near
> future: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113779. Thanks
> to Olivier for such a straight-forward and blatant example of gcc's
> inefficiency so it even woke up some gcc people. :)
> 
> On Wed, 7 Feb 2024 at 21:53, Vincent Rivière
> <vin...@fr...> wrote:
> > Hi,
> > 
> > Last August I announced GDB with PRG/ELF support. After that, we
> > worked hard 
> > on GitHub with Thorsten Otto and Miro Kropáček to polish it.
> > 
> > And finally, here it is:
> > http://vincent.riviere.free.fr/soft/m68k-atari-mintelf/archives/mint/gdb/

Re: [Freemint-discuss] GDB 14.1 for PRG/ELF

[Miro K. <mir...@gm...>]

Congratulations Vincent, you have again pulled this off. After all those
attempts during the past years, we really have a modern GCC couple with a
modern debugger.

The only thing I can add is a vague hope that some of the m68k
inefficiencies will be fixed in near future:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113779. Thanks to Olivier for
such a straight-forward and blatant example of gcc's inefficiency so it
even woke up some gcc people. :)

On Wed, 7 Feb 2024 at 21:53, Vincent Rivière <vin...@fr...>
wrote:

> Hi,
>
> Last August I announced GDB with PRG/ELF support. After that, we worked
> hard
> on GitHub with Thorsten Otto and Miro Kropáček to polish it.
>
> And finally, here it is:
> http://vincent.riviere.free.fr/soft/m68k-atari-mintelf/archives/mint/gdb/
>
> I haven't much more to say. It just works.
> Cross-compile your program with the mintelf toolchain and the -g option.
> Copy the resulting executable and the sources to your MiNT machine, then
> you
> can use GDB to debug it, at source-level. All fancy stuff is available,
> including breakpoints, display variable contents, disassembly. Even the
> very
> convenient TUI mode works like a charm in TosWin2 for full-screen
> debugging.
>
> Important:
> - ARAnyM-JIT is incompatible with GDB (it may hang). Use standard ARAnyM
> (non-JIT) instead.
> - GDB for ColdFire works well. But a bug with TRACE flag handling inside
> BaS/FireTOS causes a whole system hang on resume after breakpoint. The fix
> exists, but isn't available yet.
> - GDB should work well on other targets, as long as you have enough RAM.
>
> Enjoy 😃
>
> Note:
> For people not familiar with GDB, I've added a quickstart on the download
> page with a few useful commands.
>
> --
> Vincent Rivière
>
>
> _______________________________________________
> Freemint-discuss mailing list
> Fre...@li...
> https://lists.sourceforge.net/lists/listinfo/freemint-discuss
>


-- 
http://mikro.atari.org

[Freemint-discuss] GDB 14.1 for PRG/ELF

[Vincent R. <vin...@fr...>]

Hi,

Last August I announced GDB with PRG/ELF support. After that, we worked hard 
on GitHub with Thorsten Otto and Miro Kropáček to polish it.

And finally, here it is:
http://vincent.riviere.free.fr/soft/m68k-atari-mintelf/archives/mint/gdb/

I haven't much more to say. It just works.
Cross-compile your program with the mintelf toolchain and the -g option. 
Copy the resulting executable and the sources to your MiNT machine, then you 
can use GDB to debug it, at source-level. All fancy stuff is available, 
including breakpoints, display variable contents, disassembly. Even the very 
convenient TUI mode works like a charm in TosWin2 for full-screen debugging.

Important:
- ARAnyM-JIT is incompatible with GDB (it may hang). Use standard ARAnyM 
(non-JIT) instead.
- GDB for ColdFire works well. But a bug with TRACE flag handling inside 
BaS/FireTOS causes a whole system hang on resume after breakpoint. The fix 
exists, but isn't available yet.
- GDB should work well on other targets, as long as you have enough RAM.

Enjoy 😃

Note:
For people not familiar with GDB, I've added a quickstart on the download 
page with a few useful commands.

-- 
Vincent Rivière

Re: [Freemint-discuss] Changing memprot flags on running process

[Thorsten O. <ad...@th...>]

On Dienstag, 30. Januar 2024 15:20:41 CET Jo Even Skarstein wrote:
> if necessary abort before installing the interrupt handler.

Yes, although that is rather rude, it is better to abort with a (hopefully 
helpful) error message than just being killed by some random bus-error. Just 
don't forget to check whether memory-protection if active; if not, aborting 
won't be necessary.

Re: [Freemint-discuss] Changing memprot flags on running process

[Miro K. <mir...@gm...>]

Indeed. I have seen numerous questions and reports like SDL applications
crashing, due to the programmer forgetting to set that flag.

I guess I could add such a check in SDL, too.

On Tue, 30 Jan 2024 at 15:21, Jo Even Skarstein <jo...@on...> wrote:

> I understand, and it does makes sense. PGETFLAGS is still useful though,
> since I
> can check the flags and if necessary abort before installing the interrupt
> handler.
>
> Jo Even
>
>
>
> On Tue, 30 Jan 2024 14:22:20 +0100, Thorsten Otto <ad...@th...>
> wrote:
>
> >> On Dienstag, 30. Januar 2024 13:59:34 CET Miro Kropáček wrote:
> >> > is that you actually can't change flags of already allocated memory,
> >> > contrary what Thorsten speculated
> >>
> >> That was about using something like mprotect(), to change the
> protection flags
> >> of some memory region. But the program flags are only evaluated in the
> Pexec()
> >> call, changing them later won't work (unless you implement that
> specific case,
> >> but then you first need Mprotect() or whatever you will call it). Only
> Malloc
> >> from ALT ram flags can be changed using PSETFLAGS.
> >>
> >> Edit: maybe also protection flags for memory allocated after changing
> the
> >> flags are affected, but not protection flags for memory that is already
> >> allocated. >> _______________________________________________
> >> Freemint-discuss mailing list
> >> Fre...@li...
> >> https://lists.sourceforge.net/lists/listinfo/freemint-discuss
>
>
> _______________________________________________
> Freemint-discuss mailing list
> Fre...@li...
> https://lists.sourceforge.net/lists/listinfo/freemint-discuss
>


-- 
http://mikro.atari.org

Re: [Freemint-discuss] Changing memprot flags on running process

[Jo E. S. <jo...@on...>]

I understand, and it does makes sense. PGETFLAGS is still useful though, since I
can check the flags and if necessary abort before installing the interrupt handler.

Jo Even



On Tue, 30 Jan 2024 14:22:20 +0100, Thorsten Otto <ad...@th...> wrote:

>> On Dienstag, 30. Januar 2024 13:59:34 CET Miro Kropáček wrote:
>> > is that you actually can't change flags of already allocated memory,
>> > contrary what Thorsten speculated
>>
>> That was about using something like mprotect(), to change the protection flags
>> of some memory region. But the program flags are only evaluated in the Pexec()
>> call, changing them later won't work (unless you implement that specific case,
>> but then you first need Mprotect() or whatever you will call it). Only Malloc
>> from ALT ram flags can be changed using PSETFLAGS.
>>
>> Edit: maybe also protection flags for memory allocated after changing the
>> flags are affected, but not protection flags for memory that is already
>> allocated. >> _______________________________________________
>> Freemint-discuss mailing list
>> Fre...@li...
>> https://lists.sourceforge.net/lists/listinfo/freemint-discuss

Re: [Freemint-discuss] Changing memprot flags on running process

[Thorsten O. <ad...@th...>]

On Dienstag, 30. Januar 2024 13:59:34 CET Miro Kropáček wrote:
> is that you actually can't change flags of already allocated memory,
> contrary what Thorsten speculated

That was about using something like mprotect(), to change the protection flags 
of some memory region. But the program flags are only evaluated in the Pexec() 
call, changing them later won't work (unless you implement that specific case, 
but then you first need Mprotect() or whatever you will call it). Only Malloc 
from ALT ram flags can be changed using PSETFLAGS.

Edit: maybe also protection flags for memory allocated after changing the 
flags are affected, but not protection flags for memory that is already 
allocated.

Re: [Freemint-discuss] Changing memprot flags on running process

[Miro K. <mir...@gm...>]

Hmm, the only answer I can think of now (without digging into code) is that
you actually can't change flags of already allocated memory, contrary what
Thorsten speculated here:
https://github.com/freemint/freemint/issues/291#issuecomment-1440081036.

On Sun, 28 Jan 2024 at 20:23, Jo Even Skarstein <jo...@on...> wrote:

> What does the Fcntl(f, &flags, PSETFLAGS) call actually do?
>
> I have a small program that hooks into an interrupt vector, and I would
> like to make sure that the supervisor flags is set. So the first thing
> I do is to open a file on /proc/*.mypid, read the current flags using
> Fcntl(f, &flags, PGETFLAGS), and set the memprot flags to 0x27 with
> Fcntl(...PSETFLAGS).
>
> PGETFLAGS returns the correct flags, but setting new flags does not
> appear to do anything. As soon as the interrupt vector is called the
> system freeze. Of course, setting the supervisor flag on the executable
> works, but anyone can mess with those so I would like to set this at
> run-time.
>
> Jo Even
>
>
> _______________________________________________
> Freemint-discuss mailing list
> Fre...@li...
> https://lists.sourceforge.net/lists/listinfo/freemint-discuss
>


-- 
http://mikro.atari.org

[Freemint-discuss] OpenSSH 9.6p1

[Vincent R. <vin...@fr...>]

Hi,

Just a word to say that I've recompiled OpenSSH 9.6p1 (latest one) for 
FreeMiNT. It works like a charm.

I tested the sshd server on both ARAnyM and the FireBee. I connected as root 
from Windows using PuTTY and WinSCP. Absolutely no trouble.

I took that opportunity to write a short quickstart, for anyone who would 
like to give a try.

http://vincent.riviere.free.fr/soft/m68k-atari-mintelf/archives/mint/openssh/

Enjoy!

-- 
Vincent Rivière

[Freemint-discuss] Changing memprot flags on running process

[Jo E. S. <jo...@on...>]

What does the Fcntl(f, &flags, PSETFLAGS) call actually do?

I have a small program that hooks into an interrupt vector, and I would
like to make sure that the supervisor flags is set. So the first thing
I do is to open a file on /proc/*.mypid, read the current flags using
Fcntl(f, &flags, PGETFLAGS), and set the memprot flags to 0x27 with
Fcntl(...PSETFLAGS).

PGETFLAGS returns the correct flags, but setting new flags does not
appear to do anything. As soon as the interrupt vector is called the
system freeze. Of course, setting the supervisor flag on the executable
works, but anyone can mess with those so I would like to set this at
run-time.

Jo Even

Re: [Freemint-discuss] appl_find() behaviour

[Jo E. S. <jo...@on...>]

On Sun, 2024-01-28 at 15:39 +0100, Joakim Högberg wrote:
> 
> The program in question was an accessory called "Atari ST
> Maus-Window", coded by Thomas Binder. The little information I could
> find on it online was pretty much this:
> 
> http://www.atarimania.com/utility-atari-st-maus-window_29680.html

Aahh... I remember this, I used it a lot many years ago. And yes, this
program also triggers the problem with my test program.

- Start the test-program.
- Launch MausWind, open it's dialog and select "On".
- All instances of the test-program (and my terminal emulator) is now
killed.

Jo Even

Re: [Freemint-discuss] appl_find() behaviour

[Joakim H. <go...@gm...>]

On 28/01/2024, Jo Even Skarstein <jo...@on...> wrote:

> I'd like to test the program Joakin refers to as well, but I don't know
> what this is/where to find it.

I had no idea what that program was either, when it was first
reported. The user that stumbled upon the appl_find() problem in this
context (Kroll) is a subscriber of mint mailing list too and might
perhaps be able to explain more details if such are needed.

The program in question was an accessory called "Atari ST
Maus-Window", coded by Thomas Binder. The little information I could
find on it online was pretty much this:

http://www.atarimania.com/utility-atari-st-maus-window_29680.html

Kroll has shared his mwlight.acc with me, and I have sent a copy to Jo Even now.



-- 
Joakim Högberg
Borevägen 30
941 42  Piteå

Re: [Freemint-discuss] appl_find() behaviour

[Jo E. S. <jo...@on...>]

On Sun, 2024-01-28 at 13:15 +0000, Jo Even Skarstein wrote:
> 

> this. I will try to make a test-program to reproduce the problem.

I am able to reproduce the problem with this program (typed in, beware
of typos):

#include <aes.h>
#include <mintbind.h>

void main(void)
{
	int a = 0, b = 0;

	appl_init();

	while (1)
	{
		long d;

		Fselect(10, &d, &d, &d);
		a = appl_find((void *)(-3L << 16));

		if (a != b)
		{
			Cconws("New top application\n\r");
			b = a;
		}
	}
}

With the ec3 build an newer this program will be terminated due to a
bus error when Pure C starts. Does not happen with previous builds.

An interesting observation - if I have multiple instances of this
program running (and/or my terminal emulator) all instances will be
killed. Pure C is not killed, only the programs calling appl_find() as
in this test program. Running order does not matter, I can start the
test program and then a bunch of other programs, but as soon as I start
PureC the test program is killed.

I'd like to test the program Joakin refers to as well, but I don't know
what this is/where to find it.

Jo Even

Re: [Freemint-discuss] appl_find() behaviour

[Thorsten O. <ad...@th...>]

On Sonntag, 28. Januar 2024 14:15:33 CET Jo Even Skarstein wrote:
> So as unlikely as it seems, this change does make a difference.

That is really strange. Even if the 64 bytes additional stacksize are a 
problem, that code is only executed during startup.

Maybe something else has changed in the build environment between the two 
versions?

Re: [Freemint-discuss] appl_find() behaviour

[Jo E. S. <jo...@on...>]

I just did - downloaded and unpacked these two archives to c:/. The only change I did was to
set up a working videomode. As suspected I could still reproduce this problem every time with
he ec3 build, and never with the f40 build.

So as unlikely as it seems, this change does make a difference.

If it hadn't been for Joachim's similar findings I would have blamed my own software 100% for
this. I will try to make a test-program to reproduce the problem.

Jo Even



On Sun, 28 Jan 2024 12:28:50 +0100, "Miro Kropáček" <mir...@gm...> wrote:

>> On Sun, 28 Jan 2024 at 07:12, Thorsten Otto wrote:
>>
>> > But looking at the changes it seems strange to me that this should be the
>> > offending commit. It is only related to loading keyboard tables, and has
>> > nothing to do with XaAES.
>> >
>> Indeed. Jo Even, can you double-check (ideally redownloading just those two
>> versions, unpack and run without anything else, i.e. without your custom
>> mint.cnf/xaaes.cnf changes) ? Only thing I see there is an increased stack
>> by 64 bytes in the keyboard code and that would be quite an interesting
>> discovery.
>>
>> So after confirmation I'm happy to make a custom build/builds for you and
>> track this down.
>>
>> --
>> http://mikro.atari.org >> _______________________________________________
>> Freemint-discuss mailing list
>> Fre...@li...
>> https://lists.sourceforge.net/lists/listinfo/freemint-discuss

Re: [Freemint-discuss] appl_find() behaviour

[Miro K. <mir...@gm...>]

On Sun, 28 Jan 2024 at 07:12, Thorsten Otto <ad...@th...> wrote:

> But looking at the changes it seems strange to me that this should be the
> offending commit. It is only related to loading keyboard tables, and has
> nothing to do with XaAES.
>
Indeed. Jo Even, can you double-check (ideally redownloading just those two
versions, unpack and run without anything else, i.e. without your custom
mint.cnf/xaaes.cnf changes) ? Only thing I see there is an increased stack
by 64 bytes in the keyboard code and that would be quite an interesting
discovery.

So after confirmation I'm happy to make a custom build/builds for you and
track this down.

-- 
http://mikro.atari.org

Re: [Freemint-discuss] appl_find() behaviour

[Thorsten O. <ad...@th...>]

On Samstag, 27. Januar 2024 21:28:56 CET Jo Even Skarstein wrote:
> I truly suck at git so I can't say what has been changed between these
> builds.

The numbers in the archive names are commit ids, so you can either do 

git format-patch -1 ec33ec29 to extract the patch for that commit,

or do

git diff f40017dc ec33ec29

But looking at the changes it seems strange to me that this should be the 
offending commit. It is only related to loading keyboard tables, and has 
nothing to do with XaAES.

Re: [Freemint-discuss] appl_find() behaviour

[Jo E. S. <jo...@on...>]

Ok...

The last version I found which does not have this problem is...

   https://tho-otto.de/snapshots/freemint/bootable/freemint-1-19-f40017dc-02060-tt_falcon_clones.zip

With the next version I can reproduce the problem every time:

  https://tho-otto.de/snapshots/freemint/bootable/freemint-1-19-ec33ec29-02060-tt_falcon_clones.zip

I truly suck at git so I can't say what has been changed between these builds.

Jo Even



On Sat, 27 Jan 2024 19:41:03 +0000, "Jo Even Skarstein" <jo...@on...> wrote:

>> Good to see that I'm not the only one :) I'm going to try to find out in which version this problem appeared, this may take a while as it's quite time-consuming to test this.
>>
>> Jo Even
 

Re: [Freemint-discuss] appl_find() behaviour

[Jo E. S. <jo...@on...>]

Good to see that I'm not the only one :) I'm going to try to find out in which version this problem appeared, this may take a while as it's quite time-consuming to test this.

Jo Even



On Sat, 27 Jan 2024 19:48:03 +0100, "Joakim Högberg" <go...@gm...> wrote:

>> On 27/01/2024, Jo Even Skarstein wrote:
>>
>> > As this mostly happened to my own programs (sometimes Taskbar and very often
>> > the terminal emulator I'm
>> > working on) I assumed that this was my own fault, and started tracking down
>> > the problem. It turned out that this
>> > AES call was the problem:
>> >
>> > appl_find((char *)(-3 << 16));
>> >
>> > This returns the apid of the current top application. But sometimes this
>> > call kills the calling application
>>
>> This discovery is actually an interesting discovery. Last week a guy
>> that is helping me to test my GEM taskbar (Motosu) ran into a problem
>> with an "ILLEGAL INSTRUCTION" problem on his setup, when he
>> simultaneously had the accessory MWLIGHT.ACC loaded and active. I
>> managed to trace the crash to the exact line of failing - it was the
>> same appl_find() implementation that you are using, the one where you
>> inquire for top application.
>>
>> For this user too, it seems like ever so slight changes in the setup
>> will either make the problem go away, or alter the error from "ILLEGAL
>> INSTRUCTION" to "BUS ERROR".
>>
>> As for MWLIGHT.ACC, it does not seem to be doing anything dangerous
>> from what I can tell, apart from potentially putting a bit more stress
>> to the system.
>>
>> I believe he was using a rather recent XaAES build from autumn 2023 or
>> there about, when he experienced the crashes.
>>
>> --
>> Joakim Högberg
>> Borevägen 30
>> 941 42 Piteå

Re: [Freemint-discuss] appl_find() behaviour

[Joakim H. <go...@gm...>]

On 27/01/2024, Jo Even Skarstein <jo...@on...> wrote:

> As this mostly happened to my own programs (sometimes Taskbar and very often
> the terminal emulator I'm
> working on) I assumed that this was my own fault, and started tracking down
> the problem. It turned out that this
> AES call was the problem:
>
> appl_find((char *)(-3 << 16));
>
> This returns the apid of the current top application. But sometimes this
> call kills the calling application

This discovery is actually an interesting discovery. Last week a guy
that is helping me to test my GEM taskbar (Motosu) ran into a problem
with an "ILLEGAL INSTRUCTION" problem on his setup, when he
simultaneously had the accessory MWLIGHT.ACC loaded and active. I
managed to trace the crash to the exact line of failing - it was the
same appl_find() implementation that you are using, the one where you
inquire for top application.

For this user too, it seems like ever so slight changes in the setup
will either make the problem go away, or alter the error from "ILLEGAL
INSTRUCTION" to "BUS ERROR".

As for MWLIGHT.ACC, it does not seem to be doing anything dangerous
from what I can tell, apart from potentially putting a bit more stress
to the system.

I believe he was using a rather recent XaAES build from autumn 2023 or
there about, when he experienced the crashes.

-- 
Joakim Högberg
Borevägen 30
941 42  Piteå

Re: [Freemint-discuss] appl_find() behaviour

[Jo E. S. <jo...@on...>]

Yes, -3L << 16 is what I'm using. The call is working as intended except for in the situation I describe.

Jo Even



On Sat, 27 Jan 2024 15:32:52 +0100, Thorsten Otto <ad...@th...> wrote:

>> On Samstag, 27. Januar 2024 15:16:32 CET Jo Even Skarstein wrote:
>> > appl_find((char *)(-3 << 16));
>>
>> Just to rule out the obvious, but when you say you use Pure-C, that should be
>> -3*L* << 16 (the value has to be put in the high-word, and plain "-3" is a
>> 16bit int for Pure-C)
>>
>> If that is not the cause of your problem: only hope will be to do a bisect,
>> and try to find out which change causes the problem. But it still sounds
>> difficult, if the problem is not 100% reproducible. >> _______________________________________________
>> Freemint-discuss mailing list
>> Fre...@li...
>> https://lists.sourceforge.net/lists/listinfo/freemint-discuss

Re: [Freemint-discuss] appl_find() behaviour

[Thorsten O. <ad...@th...>]

On Samstag, 27. Januar 2024 15:16:32 CET Jo Even Skarstein wrote:
> appl_find((char *)(-3 << 16));

Just to rule out the obvious, but when you say you use Pure-C, that should be 
-3*L* << 16 (the value has to be put in the high-word, and plain "-3" is a 
16bit int for Pure-C)

If that is not the cause of your problem: only hope will be to do a bisect, 
and try to find out which change causes the problem. But it still sounds 
difficult, if the problem is not 100% reproducible.

[Freemint-discuss] appl_find() behaviour

[Jo E. S. <jo...@on...>]

I'm usually running an older kernel/XaAES (20200504), but have recently started testing newer builds to test
some programs I'm currently developing. I have noticed a change of behaviour in current builds compared to
my 2020 setup - some AES programs are being killed due to a bus error when other applications are starting.

As this mostly happened to my own programs (sometimes Taskbar and very often the terminal emulator I'm
working on) I assumed that this was my own fault, and started tracking down the problem. It turned out that this
AES call was the problem:

appl_find((char *)(-3 << 16));

This returns the apid of the current top application. But sometimes this call kills the calling application, and it
looks like this happens when the kernel or XaAES is busy starting an AES process. I have not been able to pinpoint
exactly what happens, but I notice that the more frequently appl_find is being called the more likely it is for the
calling application to be killed. E.g. in my terminal emulator it was called 100 times/seconds due to a bug, and it
was killed 95% of the times I started PureC with many (~10) open windows. When I fixed the bug and appl_find
was called two times/second the problem almost went away. If I don't do this call at all then the problem is 100%
gone.

I see the same with Taskbar, which does the same appl_find call 5 times/sec. Sometimes it's killed when a new
application is started, and it's always some "heavy" application that opens a lot of windows. It most often happens
during start-up, where Taskbar is being autostarted by the desktop, and Taskbar then autostarts a few applications.
So it seems like the problem happens when XaAES is "busy", but I'm not able to pinpoint exactly what "busy"
means in this context.

Jo Even

Re: [Freemint-discuss] QED error message

[Philippe N. <phi...@gm...>]

Hi,

I am reviving this old thread as I continue to have an error message with QED.
Tests done with Aranym (BeePi 3) and QED 5.0.5-756-040

Under Mint, QED works well, no error message.
Under Emutos QED complains that « The clipboard folder could not be created « , but the folder exists.

Philippe


> Le 26 févr. 2023 à 12:06, Philippe noble <phi...@gm...> a écrit :
> 
> Hi,
> 
> I have tested Qed 182-000 with different setups.
> The first one from Beepi 2.1 :
> Hatari 2.5-dev from 06/10/2022
> Emutos 1.2.1
> IDE drive (80 MB 4 partitions) + GEMDOS drive
> No auto, no accs 
> 
> The second one is my dev setup :
> Hatari 2.5-dev from 11/02/2023
> Emutos 1.2.1-dev from 07/02/2023
> IDE drive (512 MB 2 partitions )+ GEMDOS drive
> No auto. No accs 
> 
> Qed 182-000 was started from IDE or GEMDOS drive.
> In both cases I have the same error message.
> 
> Philippe
> 
> 
>> Le 26 févr. 2023 à 00:37, Xavier via Freemint-discuss <fre...@li...> a écrit :
>> 
>> 
>> Hi,
>> 
>> 
>> 
>> Test with Hatari 2.4.1 + EmuTOS 1.0.1, no AUTO/ACC. Hard drive is set to GEMDOS drive (host directory, no disk image) with existing CLIPBRD.
>> 
>> No error message with latest build (qed-5.0.5-182-000.zip).
>> 
>> What is your hard drive setup?
>> 
>> 
>> 
>> 
>> Le 25/02/2023 à 15:41, Philippe Noble a écrit :
>>> Hi Miro,
>>> 
>>> I did some testing and it still doesn’t work on my setup (same system as before)
>>> 
>>> Aranym + Mint : ok no problem
>>> Aranym + Emutos (no auto and accs) : clipboard message error with or without CLIPBRD or CLIPBR folder
>>> Hatari : no CLIPBRD folder : QED starts OK without error and creates CLIPBRD folder
>>> 		With CLIPBRD : error message
>>> 
>>> 
>>>> Le 25 févr. 2023 à 11:20, Miro Kropáček <mir...@gm... <mailto:mir...@gm...>> a écrit :
>>>> 
>>>> Hi Philippe,
>>>> 
>>>> can you please try the latest build from https://tho-otto.de/snapshots/qed/ <https://tho-otto.de/snapshots/qed/> ?
>>>> 
>>>> Thanks to Xavier this bug should be fixed now.
>>>> 
>>>> On Mon, 13 Feb 2023 at 16:33, Philippe noble <phi...@gm... <mailto:phi...@gm...>> wrote:
>>>> It seems to be even sweeter ;-)
>>>> 
>>>> I did some further testing.
>>>> Aranym Mint : no issue at all.
>>>> With clipbrd folder : 
>>>>       322 ok, 033 ok with several starts
>>>> Without clipbrd folder, clipbrd is created and 322 ok, 033 ok
>>>> 
>>>> Hatari 2.5-dev emutos 2023 02 07
>>>> Qed creates a clipbr folder, not clipbrd 
>>>> Without clipbr or clipbrd :
>>>>        322 and 033 ok the first run and after,
>>>> With clipbr folder :
>>>>        322 and 033 send error message
>>>> With clipbrd folder :
>>>>       322 ok, no clipbr created, second start and more ok
>>>>       033 is ok too but creates a clipbr folder and then gives the error message at the second start
>>>> 
>>>> So there is something strange.
>>>> 
>>>> Philippe
>>>> 
>>>> 
>>>> -- 
>>>> http://mikro.atari.org <http://mikro.atari.org/>_______________________________________________
>>>> Freemint-discuss mailing list
>>>> Fre...@li... <mailto:Fre...@li...>
>>>> https://lists.sourceforge.net/lists/listinfo/freemint-discuss <https://lists.sourceforge.net/lists/listinfo/freemint-discuss>
>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Freemint-discuss mailing list
>>> Fre...@li... <mailto:Fre...@li...>
>>> https://lists.sourceforge.net/lists/listinfo/freemint-discuss <https://lists.sourceforge.net/lists/listinfo/freemint-discuss>
>> _______________________________________________
>> Freemint-discuss mailing list
>> Fre...@li...
>> https://lists.sourceforge.net/lists/listinfo/freemint-discuss