Amiga.org
Operating System Specific Discussions => Amiga OS => Amiga OS -- Development => Topic started by: Minuous on June 11, 2011, 03:35:32 PM
-
The following well-known code is supposed to disable SAS/C Ctrl-C handling:
int CXBRK(void) { return 0; } /* Disable SAS/C Ctrl-C handling */
void chkabort(void) { ; } /* really */
But it does not seem to work, even when using a SCOPTIONS file containing NOCHECKABORT. My program (AmiArcadia 16.02) checks for Ctrl-C in its console window via SetSignal(). Most of the time it catches these, but sometimes it seems SAS/C's break handler catches it instead, and I get a "** User Abort Requested **" requester with option "CONTINUE" and "ABORT", Abort will shut down the program without closing the window etc, Continue lets the program continue and the Ctrl-C is ignored (my break handler doesn't catch it). This code seems to be inserted by SAS/C, as the relevant text string is embedded in the executable.
So, the question is: why isn't SAS/C's break handling turned off, and how can I do this?
Interesting, the OS4 version which is compiled with GCC apparently has a similar issue.
-
I am sure I can´t help you, but maybe you find the souliton if you ask yourself some smart questions like:
* Does your program have multiple tasks?
* Is it started from Workbench, or is the break signal sent via CLI?
Seeing the string look identical is nice, but have you patched your code or used a debugger to ensure it is really read from that memory location?
-
One more:
* are all your units of compilation (i.e. before linking) share the same definitions of chkabort and CXBRK?
-
>Does your program have multiple tasks?
No.
>Is it started from Workbench, or is the break signal sent via CLI?
It can be started from either, but to reproduce the problem I start it from Workbench and then it auto-opens the CLI window on its first printf().
>are all your units of compilation (i.e. before linking) share the same definitions of chkabort and CXBRK?
No, just one definition for the whole program. I will try a separate definition in each module and see if that helps.
-
>Does your program have multiple tasks?
No.
>Is it started from Workbench, or is the break signal sent via CLI?
It can be started from either, but to reproduce the problem I start it from Workbench and then it auto-opens the CLI window on its first printf().
>are all your units of compilation (i.e. before linking) share the same definitions of chkabort and CXBRK?
No, just one definition for the whole program. If I try separate definitions in each module the linker complains about multiply defined symbols.
-
Try:
int CXBRK(void) { return(0); } /* Disable SAS Lattice CTRL/C handling */
int chkabort(void) { return(0); }/* really */
-
The solution from Mongo should do the trick. Look here: http://cataclysm.cx/random/amiga/reference/Libraries_Manual_guide/node0019.html
-
That doesn't work either. chkabort() is defined in sc:include/dos.h as not returning anything, so making the suggested change causes a "conflict with previous declaration" error.
So I edited sc:include/dos.h to indicate that it returns an int. Now it compiles OK again but the resulting program still has the same problem.
-
Hmmm, checked some old code. All voids, no ints. Works over here.
#ifdef SAS_C
int CXBRK(void) { return(0); }
void __regargs __chkabort(void);
void __regargs __chkabort(void) {}
#endif
Edit:
Btw I thought you developed AA with Stormc (looking at the code). Why bother with sas/c ???
Ran the latest version of it (16.02) and found no problem with CTRL-C. It says 'Quitting.' and exits the program normally.
-
I would happily check my code to see how I do it but my Amiga HD is knackered :(
-
Btw I thought you developed AA with Stormc (looking at the code). Why bother with sas/c ???
Because he is intelligent enough to know that SASC Rules Them All :)
-
I propose that ur prob is caused by: you have some sort of nonstandard Shell or Console device installed. Or you have some evil hack installed (MCP, etc.) that is causing the problem.
-
If you wanna check out the _cxbrk routine, it's hidden in sc:source :idea:
-
>it auto-opens the CLI window on its first printf().
You are using printf? Doesn't this mean you are including and linking some standard C-Library stuff, which might include its own definitions for handling BRK? Are you using your own startup code?
Maybe ChaosLord is right. Try it on a "virgin Workbench". How often does the problem occur? You could write a small program/loop that does nothing but start AA (or better a third small programm that just shows the CTRL-C problem) and then send BRK .
-
@x303:
>Btw I thought you developed AA with Stormc (looking at the code). Why bother with sas/c ???
No, the release builds are built with SAS/C. In theory it is supposed to be compilable with StormC but I have not tried this with any recent version. IIRC I ran into some StormC code generation bugs. Report+ and Handy are built with StormC but the rest of my software is built with SAS/C.
>Ran the latest version of it (16.02) and found no problem with CTRL-C. It says 'Quitting.' and exits the program normally.
The actual scenario to reproduce the behaviour is this: Start AmiArcadia from WB. Switch to Galaxia. Turn on "Log inefficient code". Activate the resulting console window. Press Ctrl-C. About three-quarters of the time it says "Quitting" and quits cleanly, the other quarter of the time it is getting intercepted by SAS/C and the "** User Abort Requested **" comes up.
@Ismart/ChaosLord:
>Are you using your own startup code?
No.
>I propose that ur prob is caused by: you have some sort of nonstandard Shell or Console device installed. Or you have some evil hack installed (MCP, etc.) that is causing the problem.
>Try it on a "virgin Workbench".
OK, disabled everything in WBStartup, also disabled KingCON. Same behaviour occurs.
-
Specify DEFINE @__chkabort=@__dummy in the .lnk file, or just select NoChkAbort in the linker options via SCOptions.
-
Yeah, tried that too, but no good.
In the whole scheme of things, it's only a minor problem; I will just advise the users not to send any Ctrl-C to the console window.
-
FWIW, this works every time to either suppress or replace CTRL+C when I run it on my 6.58
-
OK, I'll check it out. Thanks.