Help me, please!
I'm at an end. I've uploaded TaskView at OS4Depot, but I discovered right after uploading that the program crashes at startup. It didn't do so when developing and compiling into a debug version (I wouldn't have released it when it did, now would I?).
After checking the released version of my program TaskView (OS4Depot), I found that it crashes (with a GR) at starting time, before the window opens.
The GR mentions that 'Redzone was damaged'.
What exactly does this mean (should I FRSFM?)?
Here's the differences between the debug version and the released version:
This is the compiler setting for the debug version (the name 'ProjecT.DEBUG' is applied to ALL projects throughout their developement):
gcc -DPROGNAME="TaskView" -DPROGREVN="3" -DPROGVERS="0" main.c -o ProjecT.DEBUG -Wall -Wextra -gstabs -DDEBUG
=== Done making DEBUG ==========================
For release the following setting is applied and now the project, any project, receives its release name, here 'TaskView':
gcc -DPROGNAME="TaskView" -DPROGREVN="3" -DPROGVERS="0" -N main.c -o TaskView -Wall -Wextra
strip TaskView
c:LhA u -x TaskView.lha TaskView TaskView.info ReadMe Catalogs/catalog.cd Catalogs/dutch/TaskView.catalog Catalogs/italian/TaskView.catalog
LhA Freeware Version 2.15 AOS4
Copyright (c) 1991-94 by Stefan Boberg.
Copyright (c) 1998,1999 by Jim Cooper and David Tritscher.
Copyright (c) 2004-2011 by Sven Ottemann.
Updating archive 'TaskView.lha':
Frozen: ( 70.1%) 51704 => 15415 : TaskView
1 file added/replaced, all files OK.
Operation successful.
=== Done making archive ==============
The difference being the debug switch '-gstabs' and the definition of 'DEBUG'. The latter does two things:
1): it defines the macro WINDOWTITLE in this way:
# ifdef DEBUG
# define WINDOWTITLE PROGNAME" - V"PROGVERS"."PROGREVN" ( DEBUG )"
# else
# define WINDOWTITLE PROGNAME
# endif
PROGNAME is set at compile time with -DPROGNAME=
2): it defines a number of macros for providing debugging info during initial run sessions:
# ifdef DEBUG
uint16 NestingCounter = 0;
CONST_STRPTR NestingIndicator = "--------------------------------------------";
# define ERROR(x) IDOS->Printf("ERROR: %s\n", x)
# define INFO(x) IDOS->Printf("INFO : * %s\n", x)
# define ELSE_ERROR(x) else IDOS->Printf("ERROR: Failed to %s\n", x)
# define ELSE_INFO(x) else IDOS->Printf("INFO : * %s\n", x)
# define TRACK(n, v) IDOS->Printf("DEBUG: Variable %30s at 0x%08X contains 0x%08X\n", n, &v, v);}
# define INFO_ENTER {NestingCounter++; IDOS->Printf("INFO : %s %s entered\n", \
(NestingCounter > 44) ? (NestingIndicator) : (NestingIndicator + (44 - NestingCounter)),\
__func__);}
# define INFO_VACATE {IDOS->Printf("INFO : %s %s vacated\n",\
(NestingCounter > 44) ? (NestingIndicator) : (NestingIndicator + (44 - NestingCounter)),\
__func__); NestingCounter--;}
# define INFO_DEADBEEF {uint32 AllocatedStack = (uint32)((struct Task *)xn->xn_Task)->tc_SPUpper - \
(uint32)((struct Task *)xn->xn_Task)->tc_SPLower; \
uint32 UsedStack = Read_DeadBeef(xn->xn_Task); \
IDOS->Printf("INFO : * Stack of %6lu bytes allocated\n", AllocatedStack); \
IDOS->Printf(" %6lu bytes used = %lu%%\n", UsedStack, \
(UsedStack * 100)/AllocatedStack);\
}
# else
# define ERROR(x)
# define INFO(x)
# define ELSE_ERROR(x)
# define ELSE_INFO(x)
# define TRACK(n, v)
# define INFO_ENTER
# define INFO_VACATE
# define INFO_DEADBEEF
# endif
A functions, ANY function, is built this way (typically):
void Build_TaskList(struct ExecParam *xn)
{
INFO_ENTER
// Stuff goes right here
INFO_VACATE
}
The macros INFO_ENTER and INFO_VACATE, as defined above, are responsible for lines like this:
INFO : ------- Build_TaskList entered
INFO : ------- Build_TaskList vacated
During initial running sessions a console window opens up and shows this info:
INFO : - main entered
INFO : -- Fill_DeadBeef entered
INFO : -- Fill_DeadBeef vacated
INFO : -- Open_Libraries entered
INFO : -- Open_Libraries vacated
INFO : -- Setup_Locale entered
INFO : -- Setup_Locale vacated
INFO : -- Open_Gadgets entered
INFO : -- Open_Gadgets vacated
INFO : -- Call_WBActivation entered
INFO : --- Call_MainBody entered
INFO : ---- Set_AlternatingPens entered
INFO : ---- Set_AlternatingPens vacated
INFO : ---- Create_Requester entered
INFO : ---- Create_Requester vacated
INFO : ---- MainBody entered
INFO : ----- Handle_WindowObject entered
INFO : ------ Handle_Events entered
INFO : ------- Build_TaskList entered
INFO : ------- Build_TaskList vacated
INFO : ------- Build_TaskList entered
INFO : ------- Build_TaskList vacated
INFO : ------- CloseWindow_Event entered
INFO : -------- IsQualifierPressed entered
INFO : -------- IsQualifierPressed vacated
INFO : ------- CloseWindow_Event vacated
INFO : ------ Handle_Events vacated
INFO : ----- Handle_WindowObject vacated
INFO : ---- MainBody vacated
INFO : * MainLoop finished successfully
INFO : ---- Remove_Requester entered
INFO : ---- Remove_Requester vacated
INFO : ---- UnSet_AlternatingPens entered
INFO : ---- UnSet_AlternatingPens vacated
INFO : --- Call_MainBody vacated
INFO : -- Call_WBActivation vacated
INFO : -- Close_Gadgets entered
INFO : -- Close_Gadgets vacated
INFO : -- Break_Locale entered
INFO : -- Break_Locale vacated
INFO : -- Close_Libraries entered
INFO : -- Close_Libraries vacated
INFO : -- Read_DeadBeef entered
INFO : -- Read_DeadBeef vacated
INFO : * Stack of 77816 bytes allocated
10988 bytes used = 14%
INFO : - main vacated
From this output you can see that the program does NOT crash when in debug mode (it would probably have stopped right after 'INFO : ---- MainBody entered').
The compiler switch '-N' has no effect to the result, meaning with or without, in both case it crashes. The 'strip' command has no influence either and neither has the 'LhA' command. This has been checked thouroughly and can therefore be ruled out.
The developement setup works for several years now, but I never, ever have encountered this behaviour!
OldFart
It means that the safety area that AmigaOS 4.x allocates in front of the stack was trashed. Likely your program needs more stack allocated in order to work properly. In that case you can fix it simply by adding a stack cookie to your program:
CONST USED TEXT stack_cookie[] = "\0$STACK: 100000"; // stack size: 100000 bytes
It's probably something simple like a missing or misplaced semicolon or misplaced braces.
What I see is that the TRACK macro in debug mode contains a } but no {. If it compiles correctly in debug mode, then in non-debug mode the } will be missing.
Similarly INFO_ENTER, INFO_VACATE and INFO_DEADBEEF contain { and } but are empty in non-debug mode. Something like this will compile but do something weird in non-debug mode:
Try to define INFO_#? as { } in non-debug mode and check if the TRACK macro is correct with } but without {.
@salass00
Added this line of code:
CONST USED TEXT stack_cookie[] = "\0$STACK: 500000";
In debug mode the result is visible in the console output:
INFO : * Stack of 503800 bytes allocated
10972 bytes used = 2%
inherently meaning it runs well.
However, release mode still crashes!
OldFart
@thomas
Hm, you spotted an old and disused macro! Removed this one from the source.
Btw, if it had been used somewhere, the compiler would have issued a complaint.
>>Try to define INFO_#? as { } in non-debug mode...
I'll try this one as well, but I have feeling that it won't matter much. These macro's have been built some 6 or 7 years ago if not earlier, but never have let me down.
Thanks,
OldFart
My concern is not about the macros alone but also about the places where they are used.
Look at this example:
In debug mode it would either do_this or do_that and then print ready in either case. In release mode it would either do_this or print ready. That's not what the programmer intended. One needs to be careful when using macros in place of function calls.
Hi thomas,
Technically speaking you are right. The situation you depict is a rather common pitfall. Especially the less trained (noobs) are prone to this. That's why I ALWAYS advocate and use this construction:
The wisdom of this way is mostly acknowledged over time.
OldFart
What surprises me most atm, is that TaskView V0.3 has been downloaded more then 40 times, but NO comments have been filed yet. Should the error then possibly be H/W-dependent? Just a thought.
OldFart
@ all
I commented out pieces of code, more and more, stage by stage, until at some point it did no longer crash. But as the creation of the window and its subsequent event-handling was in the commented-out area, there was no visible indication other then 'no crash', which I saw as a good omen.
I could now have a good look at the code and found some pointers, which i took for granted to be initialised...
In this part, the dynamically allocating of a ColumnInfo-structure, there's the mentioning of CATTEXT(), which is a macro for an otherwise lengthy, and hence error-prone, piece of code. It points to an array of texts, which are translated at programstarting time all in one go. This would not cause a problem, were it not that I decided to move the translation off into a separate process.
When in debug mode, the console output takes so much time that the translation is finished the moment the texts are to be accessed with the CATTEXT()-macro. Release mode is simply too fast for this.
I've put in an explicit delay of 50 and now it just opens up as it should: no more crashing!
The delay is a temporary fix. The final fix has to be a wait for the translation process to be finished.
With hindsight this became obvious when I placed those three IDOS->Printf() statements: the first one I placed before the ColumnInfo stuff and the other two some place after. It all falls together now. Problem can be solved now.
Thanks for all the help i got from all of you.
OldFart
C & P from AmigaWorld