Very bizarre behavior ARM64 (Pi3)

[Karl Denninger]

On 11/12/2017 12:02, Karl Denninger wrote:
> I managed to get around the Crochet blow-up I reported the other day
> with another svn update, and now can Crochet myself a running image for
> the Pi3 which boots and (at least at first blush) works.
>
> But I have code that has been running on the Pi3 (and also on the Pi2,
> along with other architectures) for quite some time that no longer runs
> when compiled on that newly-built OS.  It compiles without warnings or
> errors but blows up immediately when executed.
>
> I just tried to roll that build forward to the newly-built (FreeBSD
> 12.0-CURRENT #0 r325681M: Fri Nov 10 19:31:28 CST 2017)  -HEAD and am
> getting really bizarre core dumps, including (if compiled using OpenSSL
> libraries) a crash on initialization claiming unknown opcodes in the
> compiled binary.
>
> root at rpi3:/data/HD-MCP # lldb hd-mcp
> (lldb) target create "hd-mcp"
> Current executable set to 'hd-mcp' (aarch64).
> (lldb) run -n
> Process 1101 launching
> Process 1101 launched: '/data/HD-MCP/hd-mcp' (aarch64)
> Process 1101 stopped
> * thread #1, name = 'hd-mcp', stop reason = signal SIGILL: illegal trap
>     frame #0: 0x00000000403342e8
> ->  0x403342e8: .long  0x0ee0e000                ; unknown opcode
>     0x403342ec: ret
>     0x403342f0: stp    x28, x19, [sp, #-0x20]!
>     0x403342f4: stp    x29, x30, [sp, #0x10]
> (lldb) bt
> * thread #1, name = 'hd-mcp', stop reason = signal SIGILL: illegal trap
>   * frame #0: 0x00000000403342e8
>     frame #1: 0x0000000040082ad8
>     frame #2: 0x0000000040081ab4
> (lldb)
>
> If I compile and link with OpenSSL omitted (which is an option in the
> software in question) then I get blowups shortly after the software
> starts implying the stack is getting smashed in bizarre ways that don't
> make any sense.
>
> The same source has been running for months uninterrupted on 11.x hosted
> on a Pi2 and used to run just fine on a Pi3 from a build I last updated
> back in February.
>
> To top it off lldb blows up if I set a breakpoint (or get a SEGV and
> trap back to it) and try to print anything out of the current frame
> (e.g. the variables in the function that blew) so it's basically
> impossible to figure out what's getting hammered in the stack if I leave
> the OpenSSL libraries out.
>
> Are there known issues with the arm64 architecture in -HEAD at present?

I MAY know what is going on here; see this report:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223653

If I link without OpenSSL (no -lcrypto and no -lssl) then my code runs
fine (I have a build-time option to not use encryption of any sort for
demonstration reasons.)  But even attempting to link the SSL libraries
causes the above blowup in front of main(); a breakpoint on the first
actual statement in main() (which is an initialization of a variable) is
not reached; the trap comes first.

Why the above behavior would cause code linked with SSL libraries to
blow up on start I do not know, and there is nothing in the backtrace
that helps me identify exactly where it dies......

-- 
Karl Denninger
karl at denninger.net <mailto:karl at denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4897 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.freebsd.org/pipermail/freebsd-arm/attachments/20171113/d34b585d/attachment.bin>