Date: Mon, 13 Nov 2017 09:54:30 -0600 From: Karl Denninger <karl@denninger.net> To: freebsd-arm@freebsd.org Subject: Re: Very bizarre behavior ARM64 (Pi3) Message-ID: <1aa5d05e-d5cb-4e46-4d94-e9e51339ca0c@denninger.net> In-Reply-To: <7caae80e-876f-631c-23a9-957db7d7ddd5@denninger.net>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] 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@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@denninger.net <mailto:karl@denninger.net> /The Market Ticker/ /[S/MIME encrypted email preferred]/ [-- Attachment #2 --] 0 *H 010 `He 0 *H 00 H^Ōc!5 H0 *H 01 0 UUS10U Florida10U Niceville10U Cuda Systems LLC10U Cuda Systems CA1!0 U Cuda Systems LLC 2017 CA0 170817164217Z 270815164217Z0{1 0 UUS10U Florida10U Cuda Systems LLC10U Cuda Systems CA1%0#U Cuda Systems LLC 2017 Int CA0"0 *H 0 h-5B>[;olӴ0~͎O9}9Ye*$ g !ukvʶLzN`jL>MD'7U 45CB+kY`bd~b*c3Ny-78ju]9H euέsӬDؽmgwER?&UURj'}9nWD i`XcbGz \gG=u%\Oi13ߝ4 K44pYQr]Ie/r0+eEޝݖ0C15Mݚ@JSZ(zȏ NTa(25DD5.l<g[[Z arQQ%Buȴ~~`IohRbʳڟu2MS8EdFUClCMaѳ !}ș+2k/bųE,n当ꖛ\(8 WV8 d]b yXw ܊:I39 00 U ]^§Q\ӎ0U #0T039N0b01 0 UUS10U Florida10U Niceville10U Cuda Systems LLC10U Cuda Systems CA1!0 U Cuda Systems LLC 2017 CA @Ui0U 0 0U 0 *H :P U!>vJ n io -#ן]Wyu jǑR̀Q nƇ!G ѦF g\ yLx gw=OPycehf[ }ܷ['4ڝ\[p 6\o.B&JF" ZC{;*o*mcCcLY߾` t*S!(` ]DHP5A~/NPp6=mhk밣'doA$86hm5ӚS@ j ެEgl )0JG`%k35PaC?σ ׳HEt}!P㏏%*BxbQwaKG$6 h¦Mve; [o-Iی& I,Tc ߎ#t wPA@l0P+KXBպT zGv;NcI3&J ĬUPNa?/%W6G۟N000 k#Xd\ =0 *H 0{1 0 UUS10U Florida10U Cuda Systems LLC10U Cuda Systems CA1%0#U Cuda Systems LLC 2017 Int CA0 170817212120Z 220816212120Z0W1 0 UUS10U Florida10U Cuda Systems LLC10U karl@denninger.net0"0 *H 0 T[I-ΆϏ dn;Å@שy.us~_ZG%<MYd\gvfnsa1'6Egyjs"C [{~ _K Pn+<*pv#Q+H/7[-vqDV^U>f%GX)H.|l`M(Cr >е͇6#odc"YljҦln8@5SA0&ۖ"OGj?UDWZ5 dDB 7k-)9Izs-JAv J 6L$Ն1SmY.Lqw*SH;EF'DĦH]MOgQQ|Mٙג2Z9y@ y]}6ٽeY9Y2xˆ$T=e CǺǵbn֛{j |@LLt1[Dk5:$= ` M 00<+00.0,+0 http://ocsp.cudasystems.net:88880 U 0 0 `HB0U 0 U %0++03 `HB &$OpenSSL Generated Client Certificate0 U %՞V =;bzQ0U #0]^§Q\ӎϡ01 0 UUS10U Florida10U Niceville10U Cuda Systems LLC10U Cuda Systems CA1!0 U Cuda Systems LLC 2017 CA H^Ōc!5 H0 U 0karl@denninger.net0 *H ۠A0-j%--$% g2#ޡ1^>{K+uGE v1ş7Af&b&O; .;A5* U)ND2bF|\= ]<sˋL!wrw٧> YMÄ3\mWR hSv!_zvl? 3_ xU%\^#O*Gk̍YI_&Fꊛ@&1n } ͬ:{hTP3B.;bU8:Z=^Gw8 !k-@xE@i,+'Iᐚ:f hztX7/(hY` O.1}a`%RW^akǂpCAufgDix UTЩ/7}%=jnVZvcF<M= 2^GKH5魉 _O4ެByʈySkw=5@h.0z> W1000{1 0 UUS10U Florida10U Cuda Systems LLC10U Cuda Systems CA1%0#U Cuda Systems LLC 2017 Int CA k#Xd\ =0 `He E0 *H 1 *H 0 *H 1 171113155430Z0O *H 1B@F9%%;4</>4ԖY$ + GYB >ѡ+*9Z60l *H 1_0]0 `He*0 `He0 *H 0*H 0 *H @0+0 *H (0 +7100{1 0 UUS10U Florida10U Cuda Systems LLC10U Cuda Systems CA1%0#U Cuda Systems LLC 2017 Int CA k#Xd\ =0 *H 10{1 0 UUS10U Florida10U Cuda Systems LLC10U Cuda Systems CA1%0#U Cuda Systems LLC 2017 Int CA k#Xd\ =0 *H {ll3Q78,kTӔ(z̳QAѿY;E]GbQ{Byafv*@褕& R˺|ߗpTnf. qյ" ^J"U uӖkm\,F=#ι_,[_DVRbk,_Y_IW,ׯ,@P scߝ$D`#r _!r^0@fXYGyZČE -k' YSDִm0x+?N.ډy+Dw1]R-d$,ؤjKM-ȹn14Ա/.z!wMwᴷVMYx Q uϳq56+i&e~*e {>++Q9'ŇML%ݚм;R00vX/e%͉PTs'Y(@FM TYn W6TLRoEc]2 ghome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1aa5d05e-d5cb-4e46-4d94-e9e51339ca0c>