SIGSEGV error

[kegge13]

I would like to hope that the most simple project, an empty form, will run without any complaints in debug mode. Moreover, the debugger jumps always to the very same place, related to RtlInitAnsiStringEx. See att. The complete project is 5 MB and cannot be uploaded here. With the following link you can download it: http://downloads.kegge13.nl/?lijst=SIGSEGV The zip file hase a password (SIGSEGV) to avoid unwanted deletion at my hosting provider.

[engkin]

Can we get a stack call dump?

[guest48704]

This error was so aggravating to me, that I stayed away from lazarus for a couple of years before returning.  Here are the notes I have made on the SIGSEGV error since.

--------------------------------------------------------------------------------
SIGSEGV: This error shows up when something has not yet been created (see other
         examples below).  If the following .Create was not executed before doing
         a subsequent FileContents.LoadFromFile(filename), this error will throw.
FileContents := TStringList.Create;
--------------------------------------------------------------------------------
 Project <my project name> raised exception class 'External: SIGSEGV'.

 ln file 'MsgBxDlgUnit1.pas' at line 349:
 CentraIMsgBxButtonOK.Caption := OKBtnNm;
 
Problem MsgBxDlg1 probably hasn't been created yet. 
Look in Project/'View Project Source' to see if there is a
'Application.CreateForm(TMsgBxDlg1, MsgBxDlg1);'.  This may have to be
moved/placed in the top of the FormCreate procedure in that the MsgBxDlg1 is
needed before it has been created through the 'Project Source' area.   
--------------------------------------------------------------------------------
Project <my project name> raised exception class 'External: SIGSEGV'.

IniPropStorage1.Restore; will cause this if the restore of a subsequent form
is not created before a component (CB trying to be checked) has been restored.
--------------------------------------------------------------------------------

[howardpc]

Perhaps it is a Windows-specific problem.
The linux version of your program (both the executable you provided and a locally compiled version from the sources) runs flawlessly here.
Note in your assembler image the "ntdll" name (top line) which indicates a Windows error of some sort.

[engkin]

Is it possible to get Backtrace?

[kegge13]

Learning something every day.
Here is the output of the backtrace:
D:\Lazarus\projects\empty_form>set PATH=%PATH%;C:\lazarus\mingw\x86_64-win64\bin
D:\Lazarus\projects\empty_form>gdb project1.exe
GNU gdb (GDB) 7.3.50.20110510-cvs
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-w64-mingw32".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from D:\Lazarus\projects\empty_form/project1.exe...Reading symbo
ls from D:\Lazarus\projects\empty_form/project1.dbg...
warning: section .gnu_debuglink not found in D:\Lazarus\projects\empty_form/proj
ect1.dbg
done.
done.
(gdb) break fpc_raiseexception
Breakpoint 1 at 0x100016190
(gdb) run
Starting program: D:\Lazarus\projects\empty_form/project1.exe
[New Thread 5212.0x1558]
warning: `C:\Program Files\UltraMon\UltraMonResButtons.dll': Shared library arch
itecture i386 is not compatible with target architecture i386:x86-64.
[New Thread 5212.0x16c0]
warning: `C:\Program Files\UltraMon\UltraMonResButtons.dll': Shared library arch
itecture i386 is not compatible with target architecture i386:x86-64.
[New Thread 5212.0x158c]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 5212.0x158c]
0x0000000077c02b04 in ntdll!RtlInitAnsiStringEx ()
   from C:\Windows\system32\ntdll.dll
(gdb) backtrace
#0  0x0000000077c02b04 in ntdll!RtlInitAnsiStringEx ()
   from C:\Windows\system32\ntdll.dll
#1  0x0000000004830000 in ?? ()
#2  0x00000000000000f4 in ?? ()
#3  0x0000000000000000 in ?? ()
(gdb)


When I type "n" I get:
(gdb) n
Single stepping until exit from function ntdll!RtlInitAnsiStringEx,
which has no line number information.
[Inferior 1 (process 5212) exited normally]


Is this of enough help? The UltaMon warning should not be relevant as this was done on my desktop. The laptop does not have ultramon installed, but shows exactly the same error at exactly the same addess. Might it be a wrong implementation of the call to RtlInitAnsiStringEx?

[wp]

The complete project is 5 MB and cannot be uploaded here.

Next time you want to upload a project here remove all compiler-generated files. Add only the *.pas, *.lfm, *.lpi, *.lpr and, if available, data files to the zip, no exe, no ppu etc. Then you will end up with only a few kB.

As expected your empty_form project compiles and runs perfectly on my system (Win 10/64 bit, Laz 1.8.4/fpc 3.0.4/64 bit, or Laz trunk / fpc 3.0.4 / 32 bit)

I'd speculate that you have defective systems due to mixing 32-bit and 64-bit dlls.

[kegge13]

@WP: thank for your tips and comments.

At my office we still work with Win7/64 bits systems, not maintained by me. So I do stay at Win7 at home on a laptop and a desktop. On all systems the same error occurs.

[engkin]

Is this of enough help?

For me it is.

The UltaMon warning should not be relevant as this was done on my desktop.

UltraMon is very relevant, as it injects its code into the application. It does cause similar problems, check their forum (assuming they have one).

The laptop does not have ultramon installed, but shows exactly the same error at exactly the same addess.

A similar backtrace is needed. Notice that anti-virus and similar applications can cause this type of error. In general, any code that gets injected into your application can cause problems.

Might it be a wrong implementation of the call to RtlInitAnsiStringEx?

RtlInitAnsiStringEx is not implemented by Lazarus/FPC, it is an OS function.

As wp said, your systems are not right. You might as well have a virus on both systems.

Edit:
I just noticed that you are not the thread starter. Martin had already given a similar answer.

Your post #17 makes me think that you confuse "SIGSEGV" with "External: SIGSEGV". This thread is about the second one "External: SIGSEGV" which happens outside your code. Notice how in your second and third examples, in post #17, both are related to creation/restore of a form, and that is when UltraMon code needs to act to create/draw extra buttons or whatever.

Also, in your backtrace, you can see how UltraMon creates two additional threads:

[New Thread 5212.0x1558]  <--- the application
...
[New Thread 5212.0x16c0]  <--- UltraMon 1^st thread
...
[New Thread 5212.0x158c]  <--- UltraMon 2^nd thread

and when the error happens:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 5212.0x158c]

It seems to me it happens in UltraMon second thread: 5212.0x158c

I have no doubt that your problem is cause by UltraMon. Get rid of UltraMon and prove me wrong, please.

[kegge13]

At my office again.
Two runs of the debugger. One with UltraMon (multiple screens utility), and one without UltraMon (stopped the utility, no uninstall). In both cases still missing 160 bytes. Als at my laptop, no UltraMon installed, gives the same result. The only difference is that without UltraMon there is some explanation about these 160 bytes: used for "System startup".

H:\Lazarus\projects\effe>gdb project1.exe
GNU gdb (GDB) 7.3.50.20110510-cvs
bg
done.
done.
(gdb) run
Starting program: H:\Lazarus\projects\effe/project1.exe
[New Thread 6560.0x1994]
warning: `C:\Program Files\UltraMon\UltraMonResButtons.dll': Shared library arch
itecture i386 is not compatible with target architecture i386:x86-64.
[New Thread 6560.0x19cc]
warning: `C:\Program Files\UltraMon\UltraMonResButtons.dll': Shared library arch
itecture i386 is not compatible with target architecture i386:x86-64.
[New Thread 6560.0x19f4]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 6560.0x19f4]
0x00000000770c2b04 in ntdll!RtlInitAnsiStringEx ()
   from C:\Windows\system32\ntdll.dll
(gdb) quit
A debugging session is active.

        Inferior 1 [process 6560] will be killed.

Quit anyway? (y or n) y

H:\Lazarus\projects\effe>gdb project1.exe
GNU gdb (GDB) 7.3.50.20110510-cvs
bg
done.
done.
(gdb) run
Starting program: H:\Lazarus\projects\effe/project1.exe
[New Thread 1300.0x9e4]
[Inferior 1 (process 1300) exited normally]
(gdb)

[engkin]

What about SIGSEGV error?

[kegge13]

The SIGSEGV error was not raised in both cases through the GDB.

[440bx]

H:\Lazarus\projects\effe>gdb project1.exe
GNU gdb (GDB) 7.3.50.20110510-cvs
bg
done.
done.
(gdb) run
Starting program: H:\Lazarus\projects\effe/project1.exe
[New Thread 6560.0x1994]
warning: `C:\Program Files\UltraMon\UltraMonResButtons.dll': Shared library arch
itecture i386 is not compatible with target architecture i386:x86-64.
[New Thread 6560.0x19cc]
warning: `C:\Program Files\UltraMon\UltraMonResButtons.dll': Shared library arch
itecture i386 is not compatible with target architecture i386:x86-64.
[New Thread 6560.0x19f4]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 6560.0x19f4]
0x00000000770c2b04 in ntdll!RtlInitAnsiStringEx ()
   from C:\Windows\system32\ntdll.dll
(gdb) quit
A debugging session is active.

        Inferior 1 [process 6560] will be killed.

Quit anyway? (y or n) y

H:\Lazarus\projects\effe>gdb project1.exe
GNU gdb (GDB) 7.3.50.20110510-cvs
bg
done.
done.
(gdb) run
Starting program: H:\Lazarus\projects\effe/project1.exe
[New Thread 1300.0x9e4]
[Inferior 1 (process 1300) exited normally]
(gdb)

Given the messages you get from GDB, it seems ultramon dll is loaded dynamically and the dll is of a different bitness than the program attempting to load it.  That would explain the incompatible architecture message from GDB.

If that is the case, the dll won't load and if the program proceeds as if it had loaded, the behavior is going to be unpredictable.

Use dumpbin or objdump to determine the bitness of the dll that is being loaded.  if the dll's bitness doesn't match the program's, unexpected behavior is the least you can expect.

[engkin]

The SIGSEGV error was not raised in both cases through the GDB.

This is good for the future. Can we have the details of this OS including its Anti-Virus, if any?

We still need this tested on the previous machine, the one with SIGSEGV error. Notice that not having SIGSEGV here does not exclude UltraMon, yet. In fact UltraMon could cause a problem on two identical machines if they have different patches/updates.

Edit:
Hold a second, the SIGSEGV is there:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 6560.0x19f4]
0x00000000770c2b04 in ntdll!RtlInitAnsiStringEx ()
   from C:\Windows\system32\ntdll.dll

and it only happened when you had UltraMon running. Again, in UltraMon's second thread.