| View previous topic :: View next topic |
| Author |
Message |
bennyboos
Joined: 17 Nov 2005
Posts: 30
Location: Chester UK
|
| memory leak in gets(string) |
 Posted: Wed Oct 21, 2009 8:00 am |
 |
|
I believe I have found a memory leak in gets(string)
The disassembly code shows the compiler is using FSR0 to point to the start of my string, BUT, as each character is received it only increments FSR0L and does not check for rollover in FSR0H. Consequently, if your string is located in RAM at say, 0x0FE, after you have received two bytes, the third byte will be written to RAM at 0x000 and not 0x100 as should be the case.
| Code: | #include <18F8723.h>
#use DELAY(CLOCK=40000000)
#use RS232(UART1)
char string[10];
#locate string=0xFE
void main(void)
{
gets(string);
for(;;);
} |
My disassembly - with comments added for clarity
| Code: | 8: gets(string);
0002A 6AEA CLRF 0xfea, ACCESS Clear FSR0L to zero
0002C 0EFE MOVLW 0xfe Set FSR0H to point
0002E 6EE9 MOVWF 0xfe9, ACCESS to the start of string (0xFE)
00030 06E9 DECF 0xfe9, F, ACCESS Decrement FSR0L
00032 2AE9 INCF 0xfe9, F, ACCESS Increment FSR0L
00034 AA9E BTFSS 0xf9e, 0x5, ACCESS Have we received a byte
00036 D7FE BRA 0x34 If not jump back to the prev. line
00038 CFAE MOVFF 0xfae, 0xfef Copy byte from RCREG to INDF0
0003C 0E0D MOVLW 0xd Does INDF0 contain a carriage return?
0003E 5CEF SUBWF 0xfef, W, ACCESS
00040 E1F8 BNZ 0x32 If so, jump back 6 lines
00042 6AEF CLRF 0xfef, ACCESS Terminate our string with EOF
9: for(;;); |
Surely, it would be far better for the compiler to have used PREINCO or POSTINC0 - not only would this ensure that there is no roll-over error, but it might also lead to more compact & efficient code? |
|
 |
treitmey
Joined: 23 Jan 2004
Posts: 1094
Location: Appleton,WI USA
|
|
| Posted: Wed Oct 21, 2009 8:34 am |
|
|
If your pretty confident, then you should submit the bug to CCS.
CCS doesn't monitor these forums.
Make sure to include a complete simple test.
and perhaps your solution. 
or perhaps your asking for a 2nd pair of eyes to look over what you think is a bug. |
|
|
bennyboos
Joined: 17 Nov 2005
Posts: 30
Location: Chester UK
|
|
| Posted: Wed Oct 21, 2009 8:53 am |
|
|
Well, I've tried it using the simulator and it definately goes awry on a PIC18F8723.
My suggested fix would be as follows:-
| Code: | clrf FSR0H // Point FSR0 to the start
movlw string // of our string (whatever that may be)
movwf FSR0L
loop:
btfss PIR3, 0x5 // Have we received a bit?
bra loop // If not then loop
movf RCREG, w // Copy RCREG into WREG
movwf POSTINC0 // Copy WREG into POSTINC0
sublw 0x0D // Does WREG contain a CR ?
bnz loop // If not then loop
movf POSTDEC0, w // Otherwise rewind FSR0 one byte
clrf INDF0 // and insert EOF
|
In my tests this cured the leak and did so using one line less. |
|
|
ckielstra
Joined: 18 Mar 2004
Posts: 3680
Location: The Netherlands
|
|
| Posted: Thu Oct 22, 2009 3:16 am |
|
|
First: What is your version number? It might be you found an already solved bug.
Second: Have you submitted the bug report to CCS? As said, CCS is not monitoring this forum, so without you reporting the bug (and solution) it will never get fixed. |
|
|
bennyboos
Joined: 17 Nov 2005
Posts: 30
Location: Chester UK
|
|
| Posted: Thu Oct 22, 2009 3:33 am |
|
|
I'm sure it's the most recent one - Version 4.099. I have submitted this to CCS support as well.
I am beginning to get confused about version numbers & what I actually have.
I originally downloaded version 4.099 only to discover that the linker froze if I tried to use multiple compilation units. Having reported this to CCS they emailed me new versions of both CCSC.exe and PCW.exe that fixed things. I presumed these would manifest themselves as a different version number but when I look at Compiler Version it seems to be unchanged at 4.099 still  |
|
|
ckielstra
Joined: 18 Mar 2004
Posts: 3680
Location: The Netherlands
|
|
| Posted: Thu Oct 22, 2009 4:21 am |
|
|
You are not the only one confused by the recent version numbering, it seems like CCS has ran out of numbers with the new v4.100 being announced but not available yet. See also http://www.ccsinfo.com/forum/viewtopic.php?t=40492
It would be interesting if you could post the complete version number, including sub-versions. Post this in the above mentioned thread. |
|
|
bennyboos
Joined: 17 Nov 2005
Posts: 30
Location: Chester UK
|
|
| Posted: Thu Oct 22, 2009 5:13 am |
|
|
Of course - but how do I obtain the sub-version?
The only means I know of are either to enter CCSC +V on the command line OR go via the start button (which I suspect is the same thing)?
Either way, it only displays the main version (4.099) and not the sub-version.
These sub-versions are very subversive  |
|
|
FvM
Joined: 27 Aug 2008
Posts: 2337
Location: Germany
|
|
| Posted: Thu Oct 22, 2009 8:50 am |
|
|
You have a file version displayed in the file properties and also a signature and a file date, e.g. my most recent versions are:
PCW.exe 4.99.3.17 File Date Sep-03 17:04
PCx.dll File Date Sep-03
CCSC.exe 4.3.0.272 File Date Sep-03 17:04 |
|
|
bennyboos
Joined: 17 Nov 2005
Posts: 30
Location: Chester UK
|
|
| Posted: Thu Oct 22, 2009 9:09 am |
|
|
OK - info is as follows:-
CCSC.EXE 4.3.0.272 created 15/08/2007 21:56
PCW.EXE 4.99.19.8 15/08/2007 21:56
(Goodness only knows why the dates are this? My clock/calender is correct & I only received them a few days ago). |
|
|
Torello
Joined: 29 Sep 2006
Posts: 120
|
|
| Posted: Tue Oct 27, 2009 9:55 am |
|
|
You might want to switch back to v4093. v4099 has quite some issues. CCS is currently "optimizing" string handling and that doesn't go right in one version I guess. Please report what you've found.
I reported one on sprintf. Got a fixed pch.dll but that introduced on new issue on fprintf ...
Interesting to know if your issue is also in 4093
PS "my" sprintf issue was also in 4095. I skipped 4094 so couldn't go back to that one (when you update, the old versions are backupped in the \Picc\archive directory)
Regards,
Edwin. |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
