[fpc-pascal] How is EntryInformation.OS.haltproc assigned?

Sven Barth pascaldragon at googlemail.com
Mon Dec 4 22:43:09 CET 2017

On 04.12.2017 21:15, Juha Manninen wrote:
> I am testing with a 64-bit Manjaro Linux.
> I get an access violation when closing any LCL application built with
> QT bindings using FPC trunk. When using FPC 3.0.2 there was no access
> violation, and neither with other widgetsets. Only FPC trunk + QT
> posed a problem.
> I remember seeing this for some time, surely half a year, when testing
> FPC trunk.
> An app only says:
>   An unhandled exception occurred at $00007F180E69437C:
>   EAccessViolation:
>     $00007F180E69437C
> Breakpoints inside the app did not reveal anything.
> I wanted to find out what is happening and built FPC trunk with debug info.
> The error happens in procedure System_exit in rtl/linux/system.pp, at line:
>   EntryInformation.OS.haltproc(ExitCode);
> Backtrace is not very useful:
>  #0 SYSTEM_EXIT at system.pp:174
>  #1 fpc_do_exit at ../inc/system.inc:1076
>  #2 main at project1.lpr:20
> In debugger the data in both records "EntryInformation" and
> "EntryInformation.OS" look valid.
> Apparently the haltproc is not assigned. Where should it be assigned?
> The only place under rtl/linux I find haltproc assigned is in
> "si_dll.inc". There procedure _FPC_shared_lib_haltproc deals with
> shared libraries. Not relevant here.

haltproc is assigned in the RTL's Linux startup files. Depending on
whether the specific platform uses assembler or Pascal startup its
either rtl/linux/<cpu>/*prt0.as or rtl/linux/<cpu>/si_*.inc. The
specific file depends on whether you're linking against C-libraries
(cprt0.as, si_c.inc) or not or whether you're building a library
(dllprt0.as, si_dll.inc) or a static program (prt0.as, si_prc.inc). In
case of x86_64 the assembler files are used despite the Pascal files
already existing.

> After the crash I get an assembly window pointing to this line:
>  00007FFFF60AE37C 660f6f442410   movdqa 0x10(%rsp),%xmm0
> Isn't xmm0 a SSE2 register or something? I don't think the compiler
> generated such code.

Yes, xmm0 is a SSE2 register, but they're part of the x86_64 ABI (both
SysV and Windows) and can be used without problems as all x86_64
processers support it (with I think only the really early Athlons being

> Amazingly enough the Lazarus IDE itself when built with QT bindings
> does not crash at the end. Somehow the QT bindings are quilty but how?
> Any clues where I should look for the problem?

More information about the fpc-pascal mailing list