Persistent problem with TaskView [SOLVED]

9 posts / 0 new
Last post
OldFart
OldFart's picture
Offline
Last seen: 2 months 5 days ago
Joined: 2010-11-30 14:09
Persistent problem with TaskView [SOLVED]
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
salass00
salass00's picture
Offline
Last seen: 1 month 3 weeks ago
Joined: 2011-02-03 11:27
The GR mentions that 'Redzone
The GR mentions that 'Redzone was damaged'.
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
thomas
thomas's picture
Offline
Last seen: 2 weeks 2 days ago
Joined: 2011-05-16 14:23
It's probably something
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:
  1. if (something)
  2. do_this();
  3. else
  4. INFO_DEADBEEF
Try to define INFO_#? as { } in non-debug mode and check if the TRACK macro is correct with } but without {.
OldFart
OldFart's picture
Offline
Last seen: 2 months 5 days ago
Joined: 2010-11-30 14:09
@salass00 Added this line of
@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
OldFart
OldFart's picture
Offline
Last seen: 2 months 5 days ago
Joined: 2010-11-30 14:09
@thomas Hm, you spotted an
@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
thomas
thomas's picture
Offline
Last seen: 2 weeks 2 days ago
Joined: 2011-05-16 14:23
My concern is not about the
My concern is not about the macros alone but also about the places where they are used. Look at this example:
  1. #if DEBUG
  2. #define CALL_MACRO {do_that();}
  3. #else
  4. #define CALL_MACRO
  5. #endif
  6. if (something)
  7. do_this();
  8. else
  9. CALL_MACRO
  10. printf ("ready\n");
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.
OldFart
OldFart's picture
Offline
Last seen: 2 months 5 days ago
Joined: 2010-11-30 14:09
Hi thomas, Technically
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:
  1. #if DEBUG
  2. #define CALL_MACRO {do_that();}
  3. #else
  4. #define CALL_MACRO
  5. #endif
  6. if (something)
  7. {
  8. do_this();
  9. }
  10. else
  11. {
  12. CALL_MACRO
  13. printf("ready\n");
  14. }
The wisdom of this way is mostly acknowledged over time. OldFart
OldFart
OldFart's picture
Offline
Last seen: 2 months 5 days ago
Joined: 2010-11-30 14:09
What surprises me most atm,
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
OldFart
OldFart's picture
Offline
Last seen: 2 months 5 days ago
Joined: 2010-11-30 14:09
@ all I commented out pieces
@ 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...
  1. PD->pd_ColumnInfo = IListBrowser->AllocLBColumnInfo(LBCID_LAST, LBCIA_Column, LBCID_TASK,
  2. LBCIA_Title, CATTEXT(0),
  3. LBCIA_DraggableSeparator, TRUE,
  4. LBCIA_Weight, strlen(CATTEXT(0)) + 4,
  5.  
  6. LBCIA_Column, LBCID_STATE,
  7. LBCIA_Title, CATTEXT(3),
  8. LBCIA_DraggableSeparator, TRUE,
  9. LBCIA_Weight, strlen(CATTEXT(3)),
  10.  
  11. LBCIA_Column, LBCID_TYPE,
  12. LBCIA_Title, CATTEXT(8),
  13. LBCIA_DraggableSeparator, TRUE,
  14. LBCIA_Weight, strlen(CATTEXT(8)) + 4,
  15.  
  16. LBCIA_Column, LBCID_PRI,
  17. LBCIA_Title, CATTEXT(1),
  18. LBCIA_DraggableSeparator, TRUE,
  19. LBCIA_Weight, strlen(CATTEXT(1)) + 4,
  20.  
  21. LBCIA_Column, LBCID_NAME,
  22. LBCIA_Title, CATTEXT(2),
  23. LBCIA_DraggableSeparator, TRUE,
  24. LBCIA_Weight, strlen(CATTEXT(2)),
  25.  
  26. TAG_END);
  27.  
  28. if (PD->pd_ColumnInfo)
  29. {
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
Log in or register to post comments