Using Lazarus 1.2.4 win32 on Windows 8.1

I am getting stack traces like this:

#0 SYSTEM_FINISH_WAITFIXEDLIST$PFREELISTS at :0
#1 ?? at :0
#2 ?? at :0
#3 TRPZUDPSRV__EXECWRAPPER(<error reading variable>) at C:\pdev\rpzlib\rpzudpsrv.pas:225
#4 TRPZUDPSRV__EXECUTE(<error reading variable>) at C:\pdev\rpzlib\rpzudpsrv.pas:171
#5 CLASSES_THREADPROC$POINTER$$LONGINT at :0
#6 SYSTEM_THREADMAIN$POINTER$$LONGINT at :0
#7 KERNEL32!CreateWaitableTimerA at :0
#8 ?? at :0
#9 ?? at :0
#10 ?? at :0
#11 ?? at :0

There is a stubborn bug for example at this line:

225: application.QueueAsyncCall(@self.guitikfunc,nres);

That is the last traceable part of the source code.

Does anybody know how to enable full code tracing in the system, sysutils, etc to cover calls like
QueueAsyncCall( ) etc.

Thanks,

marco

You'll need to recompile the RTL and packages with debug information (OPT="-gl" for the "make" command line). QueueAsyncCall should normally be debuggable as AFAIK the LCL is usually compiled with debug information...

Regards,
Sven

Sven:

Thanks for your response.

I am able to recompile RTL with the following commands issues from an Admin level DOS prompt:

make clean
make all OS_TARGET=win32 CPU_TARGET=i386 OPT="-gl -O-" make install OS_TARGET=win32 CPU_TARGET=i386

How do I point the compiler to look at the new units/*.ppu

Currently, the Lazarus 1.2.4/ Fpc 2.6.4 installation puts the stock RTL units into C:\lazarus\fpc\2.6.4\units\i386-win32\
and the newly compiled RTL units into
C:\lazarus\fpc\2.6.4\source\rtl\units\i386-win32

Where would I change the internal paths of the compiler so that it now looks at the source code
and the newly compiled *.o / *.ppu files of the recompiled RTL instead of looking in the original spot?

Or must I copy the new compiled stuff into the location of the original ppu/object files?

Thanks,

marco

You should not need a Command shell with Admin rights.

I'd suggest you to install to a custom directory, e.g.:

make install INSTALL_PREFIX=c:\lazarus\fpc\2.6.4-debug

and copy over the fpc.cfg from
c:\lazarus\fpc\2.6.4\bin\i386-win32\fpc.cfg to
c:\lazarus\fpc\2.6.4-debug\bin\i386-win32 and adjust the paths in there. Then you can simply change the compiler executable inside the Lazarus settings.

Notes:
- you don't need to specify OS_TARGET and CPU_TARGET if they are the same as those of the starting compiler (e.g. you have a i386-win32 compiler installed and thus OS_TARGET and CPU_TARGET will be "win32" and "i386" respectively)
- Lazarus will automatically recompile the LCL and all packages your application uses upon the first compilation after you changed the compiler; thus the compilation might take longer the first time

Regards,
Sven

Sven:

I built the RTL as you instructed:

make install INSTALL_PREFIX=c:\lazarus\fpc\2.6.4-debug

Then I changed a single line in fpc.cfg:

From:

-FuC:\lazarus\fpc\$FPCVERSION/units/$fpctarget/rtl

To:

-FuC:\lazarus\fpc\$FPCVERSION-debug/units/$fpctarget/rtl

But I did not rebuild the compiler, only the RTL.

Now when I run, I still have a single unknown entry in the call stack. The debugger does now break inside
the RTL source code instead of the assembler windows.

What do you think it will take to get the final entry in the call stack to resolve to source code?

The RTL and LCL is fully shown in the call stack. What debug code is missing?

Another way to interpret this is the function pointer as shown in the line:

 Event(Data);

Jonas Maebe thought that somehow the heap has been corrupted. If this is the case, then the function pointer call to function pointer variable Event(Data)
could be the unknown entry in the call stack. [ #1 ?? at :0 ]

(I have a hard time thinking its a call into Win32 with a callback into fpc_ansistr_decr_ref(0xfeeefeee))

I am working on the DrMemory/HeapTrc analysis next to see what maybe memory errors could be ocurring.

Your thoughts and anybody else who wants to chime in, please feel free to do so.

Thanks to you Sven,

Marco

The current call stack of the segment fault is shown below:

#0 fpc_ansistr_decr_ref(0xfeeefeee) at
c:\lazarus\fpc\2.6.4\source\rtl\i386\i386.inc:1526 #1 ?? at :0
#2 TAPPLICATION__PROCESSASYNCCALLQUEUE(<error reading variable>) at .\include\application.inc:1079
#3 TAPPLICATION__IDLE(true, <error reading variable>) at .\include\application.inc:389
#4 TAPPLICATION__HANDLEMESSAGE(<error reading variable>) at .\include\application.inc:1273
#5 TAPPLICATION__RUNLOOP(<error reading variable>) at .\include\application.inc:1405
#6 TWIDGETSET__APPRUN(0x427860 <TAPPLICATION__RUNLOOP>, <error reading variable>) at .\include\interfacebase.inc:54
#7 TAPPLICATION__RUN(<error reading variable>) at
.\include\application.inc:1393
#8 :28

You did a "make all" inside the top level of the source? Then you have also rebuild the compiler. Simple as that... ;)

Since you also disabled optimizations by passing "OPT="-gl -O-"" to the "make all" step there shouldn't be anything missing, so the heap corruption does indeed seem more likely.

Regards,
Sven