Access violation with useless stack trace on macOS M1

[gitPr0bit]

https://lists.freepascal.org/pipermail/fpc-devel/2023-June/045156.html

How to compile:
https://lists.freepascal.org/pipermail/fpc-devel/2023-June/045158.html
(I have not tested myself, but I expect with that lldb may work, and "resolve" hopefully too)


FPC trunk:
https://lists.freepascal.org/pipermail/fpc-devel/2023-June/045159.html

You are right, it compiles as relocatable even if that flag is turned off.
I tried all the steps you suggested but, unfortunately, nothing works as expected.

I switched to FPC trunk, I compiled with -k-no_pie flag, but the flag is ignored during linking:

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

1. Error: ld: warning: -no_pie ignored for arm64

(I don't know why the message says 'no_pie', but I'm passing '-k-no_pie' as described in the post you linked).

I tried the tool https://github.com/svlobanov/disable-aslr-on-mac but memory keeps being different. I place here a couple of subsequent exceptions:

Code: Bash  [Select][+][-]

1. [FORMS.PP] ExceptionOccurred
2.   Sender=EAccessViolation
3.   Exception=Access violation
4.   Stack trace:
5.   $00000001810DFE64
6.   $000000010411ABBC
7.   $000000010408B04C
8.   $00000001040B2600
9.   $00000001040B3E90
10.   $00000001040B450C
11.   $0000000104134A34
12.   $00000001810AFD60
13.   $5C668001810DFF40
14.   $7E6F8001810AFCF8
15.   $112080010417EE38
16.   $00000001041345F8
17.   $000000010235A67C
18.   $000000010234DC30
19.   $000000010236072C
20.   $000000010234DC00
21.   $0000000180D5BF28
22. Exception at 00000001810DFE64: EAccessViolation:
23. Access violation.

Code: Bash  [Select][+][-]

1. [FORMS.PP] ExceptionOccurred
2.   Sender=EAccessViolation
3.   Exception=Access violation
4.   Stack trace:
5.   $00000001810DFE64
6.   $000000010612EBBC
7.   $000000010609F04C
8.   $00000001060C6600
9.   $00000001060C7E90
10.   $00000001060C850C
11.   $0000000106148A34
12.   $00000001810AFD60
13.   $D65B8001810DFF40
14.   $C3468001810AFCF8
15.   $8F52800106192E38
16.   $00000001061485F8
17.   $000000010436E67C
18.   $0000000104361C30
19.   $000000010437472C
20.   $0000000104361C00
21.   $0000000180D5BF28
22. Exception at 00000001810DFE64: EAccessViolation:
23. Access violation.

[Martin_fr]

-k is for fpc: meaning to pass the rest to the linker.

About trunk

I guess you need -gl -Xg and then (if you compiled packages too with (at least) -gl or -gw) the trace should be printed with units and lines already on it. (I can't test this myself at the moment).

[giuliano411]

By googling I found http://www.jakubkonka.com/2021/02/05/lldb-disable-aslr-macos.html
It appears that:

• lldb disables by default ASLR
• but with ASLR disabled it gets confused in getting symbols

The right way seems to be to ENABLE ASLR when debugging!

[Martin_fr]

By googling I found http://www.jakubkonka.com/2021/02/05/lldb-disable-aslr-macos.html
It appears that:

• lldb disables by default ASLR
• but with ASLR disabled it gets confused in getting symbols

The right way seems to be to ENABLE ASLR when debugging!

"When debugging" is something different than the above dealing with a stack trace.

If you get a stacktrace dumped by an app, while that app was not being debugged, then that trace can only be resolved if you know where the addresses were at the time that instance was running.

"When debugging" the debugger knows the current address mapping. But when the app is no longer running, those mappings are lost. (They could probably be captured along with the stacktrace, but currently are not)

[giuliano411]

Again googling, found two suggestions:

1- Disable globally ASLR: echo 0 >  /proc/sys/kernel/randomize_va_space

2- patch the executable header: Set to 0 the word at position 0x18. https://twitter.com/radareorg/status/957735289610555398

At least one of them can be adapted to MAC?

[giuliano411]

In the repository https://gitlab.com/Giuliano411/disabaslr you may find a small Lazarus app for Mac OS, named disabaslr, which can be used to clear or restore the ASLR flags in an executable, and a minimal app named crash, which creates a crash at startup, and which can be used to test the app.
Simpler than installing all the stuff from radare, to use the r2 tools.
 

[gitPr0bit]

-k is for fpc: meaning to pass the rest to the linker.

About trunk

I guess you need -gl -Xg and then (if you compiled packages too with (at least) -gl or -gw) the trace should be printed with units and lines already on it. (I can't test this myself at the moment).

I already have those flags. I attach a screenshot

[Martin_fr]

Then I don't know....

You can try to reach out on the fpc mail list, where this was suggested.

[gitPr0bit]

In the repository https://gitlab.com/Giuliano411/disabaslr you may find a small Lazarus app for Mac OS, named disabaslr, which can be used to clear or restore the ASLR flags in an executable, and a minimal app named crash, which creates a crash at startup, and which can be used to test the app.
Simpler than installing all the stuff from radare, to use the r2 tools.

I tried your tool but the "patched" version of my app's executable (i.e. after doing Reset and saving it) always gets killed. Running it from lldb I can see "error: Bad executable (or shared library)".
On the contrary, your crash example always works.

[gitPr0bit]

Then I don't know....

You can try to reach out on the fpc mail list, where this was suggested.

Ok, thank you.

[giuliano411]

I tried your tool but the "patched" version of my app's executable (i.e. after doing Reset and saving it) always gets killed. Running it from lldb I can see "error: Bad executable (or shared library)".
On the contrary, your crash example always works.

You are right. I had inadvertently tested with crash compiled for x86_64 processor. If it's compiled for arm64 it gives the same error. Apparently the reference I found was x86_64 only. Can you try to rebuild your app selecting x86_64 target? If it generates the same crash you may get useful information using this tool.

[gitPr0bit]

I tried your tool but the "patched" version of my app's executable (i.e. after doing Reset and saving it) always gets killed. Running it from lldb I can see "error: Bad executable (or shared library)".
On the contrary, your crash example always works.

You are right. I had inadvertently tested with crash compiled for x86_64 processor. If it's compiled for arm64 it gives the same error. Apparently the reference I found was x86_64 only. Can you try to rebuild your app selecting x86_64 target? If it generates the same crash you may get useful information using this tool.

I managed to build a version for x86_64 architecture but, unfortunately, it doesn't crash... So I can't get any useful information from it.

[giuliano411]

I managed to build a version for x86_64 architecture but, unfortunately, it doesn't crash... So I can't get any useful information from it.

You're making me very curious. An app which crashes only in aarch64 and not always, and which doesn't crash with lldb is rather strange.
What I'd do if I were you, I would surrender the suspect area with a number of try - except. I.e. if it crashes at startup, just surrender with try-except the very beginning of code, if I crashes later on, the area involved after the last operation with appears completed. This should not change the behavior, just address the exception to Pascal code instead that to system.

If you can share it, another possibility would be to let me have a copy, and see what happens on a similar platform, but with different settings and maybe libraries.

[Martin_fr]

Access violation crashes, if due to a dangling pointer, are hard to catch.

And evasive, any tiny change and they stop crashing. if the dangling pointer point to memory that contains something else, it may just do nothing. or it may change some random other behaviour of the app....

As I said, valgrind is good at this, But linux only.


heaptrc with keepreleased, ... well sometimes, but it wont be any good if you can't resolve the printed traces.

compiling with llvm as backend may or may not have an option. I have no idea / just something I read once...

[giuliano411]

Access violation crashes, if due to a dangling pointer, are hard to catch.

I noticed that the first entry of the stack trace doesn't change from trace to trace. As if wherever you come from you end up with the same pointer.
All the picture reminds me the situation of main bar resizing. The exception occurs in FORMS.PP i.e. when it's attempting to create the form and populate it with the widgets. A lot of calls to the cocoa interface, with concurrent thread and possible timing issues. A pointer which may get out of scope, an inappropriate "const" or something like that. Maybe some ldd on the executable may give an idea of where cocoa libraries are located, and if there's a relationship with the "constant" pointer. Maybe surrounding form.create with try-except could provide some extra info.