0
\$\begingroup\$

I'm debugging a code for the Microchip PIC18F4520 using the PROTEUS ISIS. The code was compiled with the C18 compiler. There is a very crazy bug in the code that I don't know whether it is my fault or an ISIS/PIC problem. The imagem below shows the problem.

At the function 'free', before the statement at address 1004 is executed the variable 'i' has the value 0. When the instruction is executed, the variable 'i' magically receives the value 125.

The 'heap_status' is a global variable that has no binding with the variable 'i'.

Why assigning a value to 'heap_status' affects the variable 'i'?

PS.: When the function is executed for the first time, this doesn't happen. The problem arises when the function executes for the second time.

debug

|improve this question|||||
\$\endgroup\$
  • 2
    \$\begingroup\$ What optimization level are you using when compiling? \$\endgroup\$ – Sergei_Grishin Dec 15 '14 at 4:39
  • \$\begingroup\$ The c18 optimization options shows: Enable All. But when I build the project, the output shows: "C:\Program Files (x86)\Microchip\mplabc18\v3.47\bin\mcc18.exe" -p18F4520 -ms -oa- -o- -I "C:\Program Files (x86)\Microchip\mplabc18\v3.47\bin"\\..\\h -fo build/default/production/_ext/32825281/misc.o "C:/Users/user/Desktop/EngCompTemp/8_fase/SOemb/Trabalho I/SO.X/misc.c" MPLAB C18 3.47 (feature limited) Copyright 2000-2011 Microchip Technology Inc. This version of MPLAB C18 does not support the extended mode and will not perform all optimizations. \$\endgroup\$ – user49894 Dec 15 '14 at 11:02
  • \$\begingroup\$ I disabled all the optimizations and the problem persists. \$\endgroup\$ – user49894 Dec 15 '14 at 11:10
  • \$\begingroup\$ Your parameter for the function is pointer to void. Why? Are you sure you are using it the right way? The bug sounds very odd, and I can't think of anything else. Mayve you cast a gifferent pointer type to void * and use it as another type? \$\endgroup\$ – olltsu Feb 11 '15 at 6:14
  • 1
    \$\begingroup\$ Given the number of people who can't read your images, could you please post actual code? that would be easier for us to copy/paste & try out, rather than having to run an image through OCR first ;-) \$\endgroup\$ – Mawg says reinstate Monica Nov 29 '18 at 14:35
1
\$\begingroup\$

Without seeing your code it's difficult to give advice (your screenshot is too small to read). What you see can be typically attributed to dynamic memory or auto variables when at certain point the debugger will (erroneously) show you the stack location previously occupied by a variable defined inside a function. Move the code inside a function to see if it makes a difference.

|improve this answer|||||
\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy