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
Mon, 2012-03-12 11:56
#1
Persistent problem with TaskView [SOLVED]