00:01:06 <int-e> (the corresponding code is no longer in ghc's head, beautiful)
00:08:18 <int-e> Anyway. To call back into Haskell from C, the RTS creates a trampoline, and wraps the pointer to it into some heap object with a finalizer that is supposed to free the trampoline; that's freeHaskellFunctionPtr. As a plausibility check, that verifies that the first few bytes of the code match the generated trampolines. This check is failing.
00:08:24 <int-e> Smells like memory corruption?
00:13:17 <int-e> Let me find a link: https://github.com/ghc/ghc/blob/eeead9fc9bdb5e1add09a9c3aa40df9a77d9eac3/rts/adjustor/NativeAmd64.c#L327-L351
00:13:18 <fizzie> I guess it's borderline possible some library it links dynamically to has made some sort of non-ABI-compatible change.
00:14:03 <int-e> (not that it will help much)
00:14:06 <fizzie> (Judging from the file name, this was built with ghc-8.8.4, which was a while ago.)
00:14:52 <esolangs> [[User:Hotcrystal0/Signature]] https://esolangs.org/w/index.php?diff=170758&oldid=170649 * Hotcrystal0 * (+201)
00:15:31 <int-e> ./burlesque +RTS --info might tell you
00:15:48 <int-e> (or whatever the name is)
00:16:00 <fizzie> ,("GHC version", "8.8.4")
00:17:55 <int-e> if you want to try rebuilding it you might find https://int-e.eu/~bf3/tmp/blsq.patch helpful
00:18:18 <int-e> (because manually chasing dependencies is a pain)
00:18:32 <b_jonas> memory corruption in glue code to expose a closure as a C function pointer without extra arguments? how jolly
00:19:28 <b_jonas> does the haskell FFI have a way to avoid this, by exposing closures as an explicit pair so the caller passes an argument and you can avoid the trampoline?
00:21:12 <sorear> Note that the value printed is supposed to be a *page* pointer, the fact that it doesn't end with 000 seems to indicate the pointer itself is corrupt
00:22:00 <fizzie> int-e: Thanks! Looks like I'd actually made https://0x0.st/onqe.cabal back when originally building it for myself in the "I don't know what I'm doing but it made it build" way. Will have to give rebuilding it a try when I get back to it.
00:23:54 <sorear> breakpoint on errorBelch and try to get a backtrace, maybe
00:24:18 <int-e> hope it works in `rr` so you can easily find the places that last modified it
00:25:19 <int-e> fizzie: Hah, you actually picked a meaningful version.
00:25:41 <fizzie> Can't right now, but just in case y'all want to keep on guessing, here's another observation: the pointer value it prints keeps steadily decreasing, every time by 40 bytes: https://0x0.st/Prvv.txt
00:25:47 <sorear> the offending value is a register, not memory, rr might help if the backtrace shows it was loaded from memory
00:26:10 <int-e> sorear: it dereferences that pointer, no?
00:26:44 <int-e> sorear: but right since you're saying that the pointer itself is corrupted
00:28:01 <sorear> 7ff... looks like a pointer into the stack, trying to free a local variable instead of what it points to while recursing with 40 byte frames?
00:29:41 <fizzie> 0x7ff24f42cfa8 (it's ASLR, so it's a new one) is in the mapping 7ff24f42c000-7ff24f42d000 r-xp 0000a000 00:1c 231402 /usr/lib/x86_64-linux-gnu/libffi.so.8.2.0
00:30:16 <fizzie> So not stack but code (r-xp) of a dynamically loaded library.
00:31:09 <int-e> Uh... why would this code be used if it's using libffi?
00:32:18 <fizzie> Dunno, but I do seem to have recently updated the libffi package on this system, so I imagine that's the immediate trigger for it now misbehaving.
00:32:20 <sorear> probably something in the dependencies is messed up so it's trying to use and not use libffi simultaneously
00:32:53 <int-e> Or maybe it used to get lucky and libffi trampolines looked that way, and now that stopped being the case?
00:33:50 <fizzie> (The changelog for the new version also mentions what changed was "Stop building with --disable-exec-static-tramp", which sounds quite trampoliney.)
00:34:09 <int-e> It's also funny that `grep -r ' guv'` finds *only* these adjustor related errors.
00:34:20 <sorear> ghc or libffi changelog?
00:36:20 <fizzie> (I haven't rebuilt the binary since 2020, and I don't _think_ any GHC runtime stuff gets linked to it dynamically, at least looking at ldd output.)
00:38:15 <int-e> IIUC this is the code that is supposed to be used when libffi is used for trampolines: https://github.com/ghc/ghc/blob/ghc-8.8/rts/Adjustor.c#L97-L111 ...note the absence of calling people 'guv'.
00:38:49 <int-e> I wanted https://github.com/ghc/ghc/blob/ghc-8.8.4-release/rts/Adjustor.c#L97-L111 (the release tag, not the branch) but the code is the same.
00:39:11 <fizzie> (UK, Ireland, chiefly London, informal) A form of address to a man, usually a stranger or a superior.
00:40:12 <fizzie> guv'nor: (UK, Ireland) An informal form of address to a man; see guv. This version is especially likely to be applied to the owner of a business or the landlord of a public house.
00:40:31 <int-e> Anyway. I don't have the whole story for this. There may be a hybrid scenario where libffi is used for some things and not for others.
00:40:51 <fizzie> Just to be clear, none of you need to continue thinking about this if you don't want to. :)
00:40:56 <int-e> And a bug that causes that old GHC runtime to confuse them.
00:41:05 <sorear> libffi static trampolines are 40 bytes on x86_64 without ENDBR so that's probably related
00:41:18 <int-e> fizzie: I am about done. :)
00:42:20 <int-e> fizzie: Because while it's fun to dig, there's little point in actually debugging a 5+ year old GHC version
00:43:07 <int-e> I will say that libffi changing what its trampolines look like sounds more palatable than manifesting a sudden memory corruption.
00:45:25 <int-e> b_jonas: Anyway, no I don't believe that there's a fat pointer alternative to those trampolines.
00:49:02 <int-e> fizzie: actually debugging would involve fun side quests like figuring out whether the ghc was a vanilla one or somehow patched by a distributor :)
00:53:17 <int-e> fizzie: FWIW the GHC version I used to build Burlesque recently is 9.10.3. So a slight bit behind. (But also way ahead of, say, Debian)
00:54:05 <int-e> I don't know whether 9.12 would break; I simply didn't try.
01:22:46 -!- pool9 has joined.
01:23:52 -!- pool9 has quit (Read error: Connection reset by peer).
01:23:55 -!- pool has quit (Ping timeout: 240 seconds).
01:26:08 -!- pool has joined.
01:34:02 -!- amby has quit (Quit: so long suckers! i rev up my motorcylce and create a huge cloud of smoke. when the cloud dissipates im lying completely dead on the pavement).
01:59:09 -!- pool has quit (Read error: Connection reset by peer).
01:59:34 -!- pool has joined.
04:08:11 <esolangs> [[Ruler function]] https://esolangs.org/w/index.php?diff=170759&oldid=170752 * PkmnQ * (+158) /* Implementations */
04:33:10 <esolangs> [[Special:Log/newusers]] create * Mikacat29 * New user account
05:07:38 -!- slavfox has quit (Quit: ZNC 1.8.2 - https://znc.in).
05:10:46 -!- slavfox has joined.
05:13:12 -!- sprout has quit (Ping timeout: 256 seconds).
05:14:54 -!- sprout has joined.
05:36:02 <esolangs> [[EsoFmt]] M https://esolangs.org/w/index.php?diff=170760&oldid=140905 * None1 * (-2) /* Tags */
06:10:52 <esolangs> [[Special:Log/delete]] delete * Ais523 * deleted "[[Template:Stub-2]]": unnecessary template (we already have a stub template, and having just one template instead of two helps to keep a consistent style)