[SOLVED] TFPHTTPClient.SimpleGet causes SIGILL violation error

[lbd]

Hi all

Coming from experience with other programming languages, I started programming in Pascal.

I'm working on an application that needs to connect to a REST API but I keep getting stuck at the very beginning with almost zero code.
I keep getting SIGILL violation errors.

My code:

Code: Pascal  [Select][+][-]

1. unit UMain;
2.  
3. {$mode objfpc}{$H+}
4.  
5. interface
6.  
7. uses
8.   Classes, SysUtils, Forms, Controls, Graphics, Dialogs, StdCtrls, httpprotocol, fphttpclient, fpjson, jsonparser;
9.  
10. type
11.   { TFMainForm }
12.  
13.   TFMainForm = class(TForm)
14.     buttonConnect: TButton;
15.     eFullAPIUrl: TEdit;
16.     eUsername: TEdit;
17.     ePassword: TEdit;
18.     procedure FormCreate(Sender: TObject);
19.     procedure buttonConnectClick(Sender: TObject);
20.   private
21.  
22.   public
23.  
24.   end;
25.  
26. var
27.   FMainForm: TFMainForm;
28.  
29. implementation
30.  
31. {$R *.lfm}
32. { TFMainForm }
33.   procedure TFMainForm.FormCreate(Sender: TObject);
34.   begin
35.  
36.   end;
37.  
38.  
39.   procedure TFMainForm.buttonConnectClick(Sender: TObject);
40.   var
41.     fullUrl, responseStr : string;
42.     responseJSON : TJSONObject;
43.   begin
44.        fullUrl := eFullAPIUrl.text;
45.        responseStr := TFPHTTPClient.SimpleGet(fullUrl);
46.        responseJSON := GetJSON(responseStr) as TJSONObject;
47.   end;
48.  
49. end.  
50.  

Workspace:

• Lazarus 1.9.0
• FPC: 3.0.4
• Running on Raspbian Raspberry Pi (ARM Linux)

Could anyone help a newbie out 

[rvk]

You should first check out what the content of responseStr is right after the SimpleGet. Don't just assume it has a correct JSON (or anything at all).

If it's empty then something went wrong.

Are you quering a HTTPS url ?? If so, did you install the openssl library correctly?

For the RPI I have this in my install script for the ssl stuff:
sudo apt-get -y install libssl-dev

[lbd]

It throws the error during/after TFPHTTPClient.SimpleGet when getting the responseStr.
The error is indeed solved by using a http only website. Https addresses cause the issue.

OpenSSL seems to be installed correctly (by default).

Do I need to do any manual configuration for Lazarus to let it use OpenSSL?

OpenSSL Version 1.0.1t from 3 may 2016 is currently installed.

[rvk]

OpenSSL seems to be installed correctly (by default).

Note that libssl-dev is something different than the standard openssl libraries.
It's the development headers etc.

Did you do the following command and got the message it was already installed?
sudo apt-get install libssl-dev

How did you install Laz 1.9.0?

[lbd]

Sorry for pressing "Post" too soon

I've installed the dev version as you mentioned and rebooted the RPi (just in case) but that didn't help

Lazarus 1.9.0 was installed by following this guide: https://www.tweaking4all.com/hardware/raspberry-pi/install-lazarus-pascal-on-raspberry-pi-2/
In this guide it states to do the following commands to build/install lazarus from sources.

Code: Text  [Select][+][-]

1. apt-get update
2. apt-get install -y libx11-dev libgdk-pixbuf2.0-dev libcairo2-dev gir1.2-coglpango-1.0 libpangox-1.0-dev xorg-dev libgtk2.0-dev libpango1.0-dev
3. mkdir /usr/local/lazarus
4.  
5. cd /usr/local/lazarus
6. svn co http://svn.freepascal.org/svn/lazarus/trunk source
7.  
8. cd source
9. make all OPT=-dFPC_ARMHF
10. make install OPT=-dFPC_ARMHF PREFIX=/usr/local
11.  
12. rm -rf /usr/local/lazarus

[rvk]

It throws the error during/after TFPHTTPClient.SimpleGet when getting the responseStr.

What error is thrown exactly?

What url are you using?
(maybe we can test it)

[lbd]

Using the following demo REST API url: https://reqres.in/api/users?age=2

For the sake of archiving I will mostly try to copy-paste the error instead of posting an image.

Error window with text:

Code: Text  [Select][+][-]

1. Project project1 raised exception class 'External: SIGILL'.
2. At address 75868DE8

After pressing "OK" it returns the assembler window point to:

Code: Text  [Select][+][-]

1. 75868DE8 1d0f19ee                 mrc             15, 0, r0, cr9, cr13, {0}

In assembly this points to an address after OPENSSL_init and just before OPENSSL_cleanse.

Assembler window image:
https://imgur.com/a/rzVp8

[rvk]

I'm now installing Laz on a fresh rpi.

But I've already found something that could cause it. The debugger GDB.

https://www.openssl.org/docs/faq.html#PROG16
https://stackoverflow.com/questions/25708907/ssl-library-init-cause-sigill-when-running-under-gdb

What happens if you run without the debugger?
Run > Run without debugging

[lbd]

Running without debugger didn't cause any SIGILL violation.

Is this some kind of bug that isn't in older Lazarus versions?

The stackoverflow link states that I could

Code: Text  [Select][+][-]

1. handle SIGILL nostop

but I don't know what this will do with possible future (non false-positive) errors.

[rvk]

There is also the option to use an environment setting of OPENSSL_armcap=7 or 0
Not sure if that will solve it.

But I tested here with a freshly installed Lazarus trunk and I didn't get the SIGILL.

Lazarus 1.9.0 r57601 FPC 3.1.1 arm-linux-gtk2
GDB version: GNU gdb (Raspbian 7.12-6) 7.12.0.20161007-git
openssl 1.1.0f-3+deb9u1 armhf

You could try a update to get the latest versions.
sudo apt-get update
sudo apt-get -y upgrade

Maybe the latest version of openssl and gdb 7.12-6 play nicer together.

Code: Pascal  [Select][+][-]

1. uses fphttpclient;
2.  
3. procedure TForm1.Button1Click(Sender: TObject);
4. var
5.   fullUrl, responseStr : string;
6. begin
7.    fullUrl := 'https://reqres.in/api/users?age=2';
8.    responseStr := TFPHTTPClient.SimpleGet(fullUrl);
9.    Memo1.Lines.Add(ResponseStr);
10. end;

[lbd]

I tried an update and upgrade but that didn't update GDB and OpenSSL.

I found a walkthrough on how to update GDB but none about updating OpenSSL (atleast not to update to the most recent version that is Raspbian Jessie compliant):
https://www.raspberrypi.org/forums/viewtopic.php?t=104827

I've updated GDB to version 7.12.1 through this guide, however that alone didn't fix the issue.

The Raspberry Pi runs on Raspbian Jessie we're currently not able to update it to the latest Stretch version as it might break current in-house dependencies.

Could you maybe help me point to the right direction to try?:
- Setting the environment setting of OpenSSL to OPENSSL_armcap=7 or 0
- Update OpenSSL to a later version, if possible, for Raspbian Jessie


Btw, Thank you so much for the effort in helping me out! 

[rvk]

- Update OpenSSL to a later version, if possible, for Raspbian Jessie

You could try setting a repository to a newer version but that might screw up other packages too, so it's not advised.

- Setting the environment setting of OpenSSL to OPENSSL_armcap=7 or 0

Easiest solution is to add the following line to ~/.profile at the end

Code: [Select]

export OPENSSL_armcap=7Logout and log back in and the error message stays away (confirmed with 2016-05-27-raspbian-jessie.img and OpenSSL 1.0.1t and GDB 7.7.1).

PS. This is tested with a RPI 3B and should also work for RPI 2 (Arm7). If you still have a RPI 1 (Arm6) you might need to set it to 6.

[Thaddy]

Note I see an alarming amount of "issues" with ssl code in any language, not just Lazarus or FreePascal or in your case Jessie vs Stretch.
The cause is usually that Openssl and major browsers dropped support for insecure protocols. And this time really fast! within months.
You may want to review the exact protocols you are using: these may not be adequate....
The compile failure(s) can simply be caused by a call to something that is no longer there.....A lot has been removed in an openssl standard compile.

Anyway: you have to fix this in the proper context. If you are using wrong or deprecated protocols there is no way you can "massage" any programming language to still work as it used to.
This is a case of global internet infrastructure.

Examples: sslv2/3 tls1.0 but also multiple deprecated low value hashes are no longer supported in openssl and others. Which includes all major browsers.
Hence you need to rewrite your code to support current standards, not try and make your old code work......There is a reason for that...

[rvk]

The compile failure(s) can simply be caused by a call to something that is no longer there.....A lot has been removed in an openssl standard compile.

It was not a compile failure. It was an error from GDB debugger while running. OpenSSL 1.0.1t throws an "internal" SIGILL which GDB catches. It's thrown in the initialization of OpenSSL when it queries all the CPU capabilities. It seems to be resolved with newer OpenSSL versions. Adding the OPENSSL_armcap=7 also fixes this for older versions.

Anyway: you have to fix this in the proper context. If you are using wrong or deprecated protocols there is no way you can "massage" any programming language to still work as it used to. This is a case of global internet infrastructure.

It had nothing to do with the actual protocols. Just the initialization part of OpenSSL.
See the earlier mentioned links:
https://www.openssl.org/docs/faq.html#PROG16
https://stackoverflow.com/questions/25708907/ssl-library-init-cause-sigill-when-running-under-gdb

It's solved with adding export OPENSSL_armcap=7 to the ~/.profile.

Although upgrading to stretch might also be considered a better option.

Hence you need to rewrite your code to support current standards, not try and make your old code work......There is a reason for that...

For this particular problem, setting OPENSSL_armcap is a perfectly acceptable solution and even advised.

Two options. Either set explicit capability environment variable in order to bypass the capability query (see corresponding crypto/*cap.c for details). Or configure debugger not to stop upon SIGILL exception, e.g. in gdb case add 'handle SIGILL nostop' to your .gdbinit.

[Thaddy]

Rik my comment was a note. Because I see this in real life.
I respect your explanation, but really? an environment setting? as a fix? in production?

Anyway I am curious to fix this in a proper way.