AnsweredHot!XC16 1.3x Compiler Memory Corruption

Author
Peter Sikora
Starting Member
  • Total Posts : 29
  • Reward points : 0
  • Joined: 2003/11/07 12:46:46
  • Location: Brisbane Australia
  • Status: offline
2017/12/06 08:00:19 (permalink)
0

XC16 1.3x Compiler Memory Corruption

I am having a problem after many frustrating attempts to compile a graphics project on the PIC24FJ256DA210 demo board.
After adding a new project sheet or simply adding a few characters to a string variable, when I compile I get no errors but the results are mixed on the display. By that I mean sometimes I just get a constant reset, other times I get display memory corruption or sometimes I get nothing at all. The only solution I have found that seems to work is by going into the compiler settings under XC16-GCC and ticking or un-ticking the box that says "Place Data Into it's own section". I am not sure if this is just coincidental or has something to do with the issue. Has anyone else had symptoms like this at all?
#1
Peter Sikora
Starting Member
  • Total Posts : 29
  • Reward points : 0
  • Joined: 2003/11/07 12:46:46
  • Location: Brisbane Australia
  • Status: offline
Re: XC16 1.3x Compiler Memory Corruption 2017/12/07 09:01:18 (permalink)
0
Tail between my legs and walking home in shame. Well not really. Found I had the wrong de-reference value set in an object linked list search so it was never finding the end until somewhere it ran out of memory to search. Still you would think the compiler would alert you and not behave in such a way that the fault should somehow correct itself. I't bad enough wrestling with MPLAB x and it's clumsy over zealous need to place corrections over the whole of your page before you have even finished a line. Oddly enough it doesn't shed any light on why I could get such a consistent result ticking those boxes.
 
Just in case someone was listening!
#2
Gort2015
Klaatu Barada Nikto
  • Total Posts : 1551
  • Reward points : 0
  • Joined: 2015/04/30 10:49:57
  • Location: 0
  • Status: offline
Re: XC16 1.3x Compiler Memory Corruption 2017/12/07 10:20:59 (permalink)
4 (1)
I prefer the editor to not check like in asm.

MPLab X playing up, bug in your code? Nevermind, Star Trek:Discovery will be with us soon.
https://www.youtube.com/watch?v=Iu1qa8N2ID0
+ ST:Continues, "What Ships are Made for", Q's back.
#3
Peter Sikora
Starting Member
  • Total Posts : 29
  • Reward points : 0
  • Joined: 2003/11/07 12:46:46
  • Location: Brisbane Australia
  • Status: offline
Re: XC16 1.3x Compiler Memory Corruption 2017/12/09 07:23:15 (permalink)
0
Yes well I am still having issues with MPLAB X 4.05 doing all kinds of weird stuff like not recognizing the removal of a source file until I restart.
#4
Gort2015
Klaatu Barada Nikto
  • Total Posts : 1551
  • Reward points : 0
  • Joined: 2015/04/30 10:49:57
  • Location: 0
  • Status: offline
Re: XC16 1.3x Compiler Memory Corruption 2017/12/09 16:33:08 (permalink) ☼ Best Answerby Peter Sikora 2017/12/09 19:19:12
3 (1)
This is normal.  Like my old tv set, the manufacturer said that the tv has issues but would not admit that it was Basil Faulty.
 
I know exactly what you mean.
Try rename or move a file from 1 project to another.
 
Worst still, add a new file to your project.  On next mplab x start, immediately add the file again because it won't be there.  Don't touch the editor first otherwise it will not be there again on next start.  I thought, "editor", great, I can edit files but alas, no, you have to go through the same rigmarole every <> time.
 
Catastrophic affect: You won't be able to compile anything ever again.  Effect: Project Properties  empty.

Rename a library, do it this way.
1. Remove .X first from libraries
2. Rename project library
3. Re-compile project library
4. Add .X back to libraries.
post edited by Gort2015 - 2017/12/09 16:54:49

MPLab X playing up, bug in your code? Nevermind, Star Trek:Discovery will be with us soon.
https://www.youtube.com/watch?v=Iu1qa8N2ID0
+ ST:Continues, "What Ships are Made for", Q's back.
#5
Gort2015
Klaatu Barada Nikto
  • Total Posts : 1551
  • Reward points : 0
  • Joined: 2015/04/30 10:49:57
  • Location: 0
  • Status: offline
Re: XC16 1.3x Compiler Memory Corruption 2017/12/09 16:52:34 (permalink) ☄ Helpfulby Peter Sikora 2017/12/09 19:19:28
4 (2)
Wait until you get fantom editing.
 
This where you spend an hour editing some code, compile then run it on the chip.
 
What actually happens is that the compiler is refering to some ealier version of the code.
You make changes and they appear on the screen.
 
Again.  Restart and you find all that editing went down the Swanny.

MPLab X playing up, bug in your code? Nevermind, Star Trek:Discovery will be with us soon.
https://www.youtube.com/watch?v=Iu1qa8N2ID0
+ ST:Continues, "What Ships are Made for", Q's back.
#6
NKurzman
A Guy on the Net
  • Total Posts : 15134
  • Reward points : 0
  • Joined: 2008/01/16 19:33:48
  • Location: 0
  • Status: online
Re: XC16 1.3x Compiler Memory Corruption 2017/12/09 18:29:56 (permalink) ☄ Helpfulby Peter Sikora 2017/12/09 19:19:35
3 (1)
Gort2015
Wait until you get fantom editing.
 
This where you spend an hour editing some code, compile then run it on the chip.
 
What actually happens is that the compiler is refering to some ealier version of the code.
You make changes and they appear on the screen.
 
Again.  Restart and you find all that editing went down the Swanny.


Try a save all.  For MplabX The compiler works from the Disk, not the screen.  if the IDE does not save, then you are working off the last save.  
FYI: this is not true of all IDEs  some work from the screen, not the disk.  That has its own problems.
#7
Peter Sikora
Starting Member
  • Total Posts : 29
  • Reward points : 0
  • Joined: 2003/11/07 12:46:46
  • Location: Brisbane Australia
  • Status: offline
Re: XC16 1.3x Compiler Memory Corruption 2017/12/09 19:19:43 (permalink)
3.5 (2)
I have found exactly the same problem as Gort2015. I have even had the IDE delete the contents of a source file leaving it empty even thought the page on screen shows all the content is there and saved. The Save all button is inactive. When I re-opened the project after closing that whole file contents was gone only a blank sheet. God knows how many updates they have done since first release I can only assume that 4.05 means at least 4050 major re-works. Never mind the minor ones we don't get to see. I know it's a tough job writing software but you would think they could get it right by now. It was a big mistake to go to netbeans and java from debugging point of view. It is extremely slow to traverse your code having to wait for all the variables to catch up. I am not using it as a hobby. It is costing my business real money. I have invested a lot in Microchip products but if they continue to go this way I may consider abandoning them in favor of someone less problematic. Thanks to all for your input.
#8
T Yorky
Super (Thick) Member
  • Total Posts : 460
  • Reward points : 0
  • Joined: 2012/08/28 02:07:35
  • Location: UK
  • Status: online
Re: XC16 1.3x Compiler Memory Corruption 2017/12/10 04:19:07 (permalink)
3 (1)
@ Peter,
Ditto.
Some 'naughty stuff' as well. An example, PIC24FJ1024GB, V3.26 shows XC compiler V1.26 as tested and compatible. Then V4.01 shows V1.26 as not compatible. Now was it tested and correct, or did somebody realise they made an assumption and actually missed the stuff added later (V1.32)? This does not inspire confidence especially when working with new products and addressing the possiblity "its probably my new configuration that is wrong and why i'm spending days on what normally takes minutes".
T Yorky.
#9
Peter Sikora
Starting Member
  • Total Posts : 29
  • Reward points : 0
  • Joined: 2003/11/07 12:46:46
  • Location: Brisbane Australia
  • Status: offline
Re: XC16 1.3x Compiler Memory Corruption 2017/12/10 05:28:06 (permalink)
0
I just spent 2 days trying to work out why my linked list of graphics objects was failing when the objects were registered (Stored) in a different order. malloc was somehow corrupting the memory allocation. I admit I don't know the nitty gritty of how malloc allocates memory on a pic24 but then again all I want to know is that it's compliant. I finally pieced together a method for allocating the NextRecord pointer in my object registration struct and am about to test it out on my graphics project. I will post the results after testing. But in the mean time I have a warning
        ListPointerMain.c:117:29: warning: assignment from incompatible pointer type for this line
        (*pList->pNextR).pNextR = pList->pCurrent;
 
because I have this declared in one struct ,
        typedef struct {
        struct RECRD*   pNextR;
        }RECRD;
 
and this in the other is,
        typedef struct _R_LIST{
        int       Items;                // Items in the list
        RECRD*   pHead;           // Pointer to the Head of the list
        RECRD*   pCurrent;       // Pointer to current record being saved
        RECRD*   pNextR;         // A pointer to the next record in list.
        }R_LIST;
 
The part the compiler takes offense at is the I declared one struct RECRD* and the other RECRD*
The thing is I can find no reference examples that require a type cast from one to the other. But then again a lot of the examples are purely skeleton structures that have no hope of working the way they are presented.
#10
Gort2015
Klaatu Barada Nikto
  • Total Posts : 1551
  • Reward points : 0
  • Joined: 2015/04/30 10:49:57
  • Location: 0
  • Status: offline
Re: XC16 1.3x Compiler Memory Corruption 2017/12/10 10:58:52 (permalink)
0
(*pList->pNextR).pNextR = pList->pCurrent;
No need for casting, try this:
pList->pNextR->pNextR = pList->pCurrent;
 
With objects, the object is a container or a pointer.
Also typedef should have a "_t" at the end. typedef struct{int x;}Data_t;
 
I don't use malloc.
I have my own object library and memory allocator.  Very small and efficient.
This is my C header file.
/* 
 * File:   ObjectLib2.h
 * Author: Gort1951
 *
 * Created on 25 June 2014, 16:28
 */
//----------------------------------------------------
#ifndef OBJECTLIB2_H
#define    OBJECTLIB2_H

#ifdef    __cplusplus
extern "C" {
#endif
#include <stddef.h>
//----------------------------------------------------
 typedef struct{
    struct Object_t    *Prev;
    struct Object_t    *Next;
    int                 Flag;
}Object_t;
//----------------------------------------------------
#define OERROR_OK                   0
#define OERROR_NULL                 1
#define OERROR_ATTACHED                2
#define OERROR_NOTATTACHED            3
#define OERROR_NEWATTACHED            4
#define OERROR_NULLB                5
#define OERROR_ATTACHEDB            6
#define OERROR_NOTATTACHEDB            7
#define OERROR_NEWATTACHEDB            8
#define OERROR_NOTINIT              9
#define OERROR_MEMORYALLOC         10
#define OERROR_MEMORYALREADYSET    11
#define OERROR_SIZE_T              12
#define OERROR_ALREADYFREE         13
#define OERROR_NOTFOUND               14
#define OERROR_LISTEMPTY           15
#define OERROR_INDEX               16
#define OERROR_LOCKED              17
#define OERROR_MASTERLOCK          18
//----------------------------------------------------
extern Object_t
   *obj_fromindex       (unsigned int),     //error in O_Error if null
   *obj_head            (),
   *obj_new             (unsigned int Size),
   *obj_next            (const Object_t *Object),
   *obj_prev            (const Object_t *Object),
   *obj_tail            ();
extern int
    obj_allocmem        (void *Memory, unsigned int Size),
    obj_append          (const Object_t *AppendObject),
    obj_find            (const Object_t *FindObject),
    obj_free            (const Object_t *Object),   //return inuse, null or ok
    obj_geterror        (),
    obj_insert          (const Object_t *Object, const Object_t *NewObject),
    obj_lock            (const Object_t *Object),
    obj_makehead        (const Object_t *Object),
    obj_maketail        (const Object_t *Object),
    obj_remove          (const Object_t *Object, int Count), // -/+
    obj_unlock          (const Object_t *Object);
extern unsigned int
    obj_getcount        (),
    obj_getfreemem      (),
    obj_indexof         (Object_t *Object);         //get index of object in list
//----------------------------------------------------
//utility
extern void
    list_allobj         (),
    list_thisobj        (const Object_t *Object);
//----------------------------------------------------
//memory management
extern void
   *mem_new             (size_t Size);
extern int
    mem_free            (void *Memory),
    mem_getfree         (),
    mem_getused         (),
    mem_preserve        (void *MemoryAddress, int Size);
//----------------------------------------------------
#ifdef    __cplusplus
}
#endif
#endif    /* OBJECTLIB2_H */


MPLab X playing up, bug in your code? Nevermind, Star Trek:Discovery will be with us soon.
https://www.youtube.com/watch?v=Iu1qa8N2ID0
+ ST:Continues, "What Ships are Made for", Q's back.
#11
Gort2015
Klaatu Barada Nikto
  • Total Posts : 1551
  • Reward points : 0
  • Joined: 2015/04/30 10:49:57
  • Location: 0
  • Status: offline
Re: XC16 1.3x Compiler Memory Corruption 2017/12/10 16:09:25 (permalink)
3 (1)
NKurzman
Gort2015
Wait until you get fantom editing.
 
This where you spend an hour editing some code, compile then run it on the chip.
 
What actually happens is that the compiler is refering to some ealier version of the code.
You make changes and they appear on the screen.
 
Again.  Restart and you find all that editing went down the Swanny.


Try a save all.  For MplabX The compiler works from the Disk, not the screen.  if the IDE does not save, then you are working off the last save.  
FYI: this is not true of all IDEs  some work from the screen, not the disk.  That has its own problems.


I'm always saving, I have to because I get the other bug, mplabx just vanishes and you are back on the desktop.  This bug started when I removed v4 and went back to some earlier version 3.
 
Fanthom - It can just occur, you don't even know when it could happen. Everything appears normal until you make some noticeable change like displaying a message on an lcd and that message does not appear.
It has been a while but I've seen it happen 4 times so far.
 
The first time I was baffled, triple checking code that I already know works. Printing a message to the lcd, bug printing, bug in lcd, spi etc.
 
It wasn't until a restart that I saw that none of my code had changed. Not just in main and files but also in a library edit.  It appeared to compile.  For some reason no edit changes were being saved, even the disk icon grayed after a ctrl 's'.
 
The edit appeared on screen as normal leaving you none the wiser.
 
I do not know if this starts on a new session or while editing.  Maybe mplab x ran out of memory because we know how poorly it handles that.
 
mplabx does not like cloned windows, noticed on v4.05 there is a new search bug.
Clone a file and search for some text, now mplabx scrolls to the found text in the original file window meaning that you loose your place in the file that you wanted to stay at that position.
 
Cloning to see another part of the program not in view and mplab x now destroys that.
Cloning is not color scheme friendly either in asm.  My mnemonics are the same color as my directives.
 
I never use mplab x debugging, I would not trust the results.
 
When I close mplab x, sometimes just after starting (due to another mplab x bug *1), I have to close it earlier (click X icon in corner, not forcing it to close via Task Manager) due to the fact *2.
 
I don't want it still running.
 
 
*1. error from project properties, pickit not found but I'll tell you that 20+/- times just to annoy you.
 
*2. 20 popups of project->properties are now going to appear on the screen.
 
You restart, it could happen on the 2nd run.
This occurs every two weeks at least.
 
 
Sort it out Microchip.

MPLab X playing up, bug in your code? Nevermind, Star Trek:Discovery will be with us soon.
https://www.youtube.com/watch?v=Iu1qa8N2ID0
+ ST:Continues, "What Ships are Made for", Q's back.
#12
Peter Sikora
Starting Member
  • Total Posts : 29
  • Reward points : 0
  • Joined: 2003/11/07 12:46:46
  • Location: Brisbane Australia
  • Status: offline
Re: XC16 1.3x Compiler Memory Corruption 2017/12/10 17:22:55 (permalink)
0
Thanks Gort2015, I tried your suggestion pList->pNextR->pNextR = pList->pCurrent; with the same result
The compiler wants me to do this pList->pNextR->pNextR = (struct RECRD* )pList->pCurrent; before it removes the warning.
 
From what I understand of linked list is it should work like this!
 
This is the flow diagram
see attached: Malloc_1.jpg
 
 
The first record should be:
pList->pHead = malloc(sizeof(RECRD));
 
Subsequent records should be:
(*pList).pCurrent = malloc(sizeof(RECRD));
or I could use pList->Current = malloc(sizeof(RECRD));
Am I understanding this correctly?
post edited by Peter Sikora - 2017/12/10 17:28:31

Attached Image(s)

#13
T Yorky
Super (Thick) Member
  • Total Posts : 460
  • Reward points : 0
  • Joined: 2012/08/28 02:07:35
  • Location: UK
  • Status: online
Re: XC16 1.3x Compiler Memory Corruption 2017/12/11 02:42:52 (permalink)
0
@ Gort2015,
I have experienced the same with MPlabX. I suspect that the developers are all Linux background and do not test properly on Windows. Trusting Netbeans. But only a guess.
However, an answer based upon my own observations, the files are saved BUT not where you expect them to be. Hover your mouse over the tab (I use tabbed view) of the project file (eg. main.c). The hint will show you the full path of where MPLabX is storing the file.
I found that when swapping projects/files in different folders, MPLabX does not update the path so you may actually be editing your backup!
I'm sure most are aware of MPLabX not updating the Window Caption Bar with the correct project name. This hasn't been corrected in ?? years!!! (Please ref: hitchhikers guide to the galaxy for 'Not My Problem'!!)
I regularly pass projects between myself and a customer to test on their hardware. We have to adhere to strict rules with MPLabX when copying and locating project folders between our different machines. MPLab 8 didn't matter, no issues.
@Peter Sikora,
Look up memory control blocks, which were used by DOS back in the day. Although these are a bit more involved than what you need they do show the principle. Normally the link is stored as void *. This is then cast to a structure pointer when used. This was generally to overcome the 'chicken before the egg' problem for some compilers. Looked at your pic, is the arrow the wrong way round? normally start at the beginning and hop forward. Also for info malloc is system specific. Your pointers should really be 32 bit in PIC24 if you want your code to be universal. Storing page and address. If you want to manage memory yourself. The linker script can be edited to exclude a block of data that will not be allocated by the compiler.
T Yorky.
 
#14
Gort2015
Klaatu Barada Nikto
  • Total Posts : 1551
  • Reward points : 0
  • Joined: 2015/04/30 10:49:57
  • Location: 0
  • Status: offline
Re: XC16 1.3x Compiler Memory Corruption 2017/12/11 12:11:59 (permalink)
5 (1)
pList->pHead = malloc(sizeof(RECRD));
 
Check return value of malloc.

MPLab X playing up, bug in your code? Nevermind, Star Trek:Discovery will be with us soon.
https://www.youtube.com/watch?v=Iu1qa8N2ID0
+ ST:Continues, "What Ships are Made for", Q's back.
#15
Gort2015
Klaatu Barada Nikto
  • Total Posts : 1551
  • Reward points : 0
  • Joined: 2015/04/30 10:49:57
  • Location: 0
  • Status: offline
Re: XC16 1.3x Compiler Memory Corruption 2017/12/11 14:34:11 (permalink)
0
Always error check, never assume.  Trap error:
if((pList->pHead = malloc(sizeof(RECRD)))==NULL) return ERR_ALLOC; //exit on error
..
..
..
return ERR_OK;

MPLab X playing up, bug in your code? Nevermind, Star Trek:Discovery will be with us soon.
https://www.youtube.com/watch?v=Iu1qa8N2ID0
+ ST:Continues, "What Ships are Made for", Q's back.
#16
Jump to:
© 2017 APG vNext Commercial Version 4.5