libera/#sbcl - IRC Chatlog

0:13:57 waleee I built sbcl with --fancy so it descends to the low level

0:14:08 waleee (after the SIGABRT)

0:14:16 stassats --fancy doesn't affect debugging

0:14:46 waleee I assumed it enabled all debuggers

0:15:12 waleee -s

0:18:10 stassats i removed that NIL is not of type SB-KERNEL:CODE-COMPONENT, but i guess the debugger can still go haywire on unknown traps

0:18:18 waleee are all points in "1.3.2 Signal Related Bugs" of http://www.sbcl.org/manual/ up to date? (re the change needed to runtime.h)

0:18:49 stassats you don't have a signal related bug

0:20:34 waleee that would only be necessary for signals sent by sbcl?

0:21:15 stassats just don't worry about that part of the manual

0:21:20 stassats i don't know what it's there at all

0:21:29 waleee ok

0:21:34 stassats what's even a signal related bug

0:22:53 stassats waleee: doesn't g_log print anything useful before dying?

0:22:57 karlosz welp, temp-reg-tn is in fact going away

0:23:10 karlosz what am i supposed to use for 64 bit fixups

0:23:21 karlosz there's no lip or anything on x86

0:23:36 stassats temp-reg-tn-redux

0:25:10 karlosz i wonder if dougk is freeing up r11 for anything in particular

0:25:36 stassats for everything?

0:26:00 karlosz like, an extra reg, or another wired tn to hold some metaspace thingy

0:26:03 karlosz whatever metaspace is

0:26:04 waleee there is a warning about xdg-desktop-access protocol some lines before

0:26:24 karlosz i wish layout stayed layout and not wrapper though, now the comments everywhere are outdated

0:26:59 karlosz and i've run into another issue; callbacks are broken

0:27:09 karlosz i wonder if that's because some linkage table thing assumes 32 bit space

0:27:45 karlosz get a memory fault at #xffffffffdebd04b0, so probably some truncated/sign extended issue

0:30:36 waleee stassats: that debug change gave an error during the build instead, https://0x0.st/-0gD.txt

0:32:26 stassats it's not the change, obviously

0:38:19 karlosz waleee: try reverting the change starting with "Generalize ...", that was committed at the same time

0:38:47 karlosz that one is borked

0:39:05 waleee ah. right, tig is a bit annoying when listing commits by time

0:39:37 waleee (it defaults to using the commiters local time)

0:46:10 stassats i reported it to the appropriate channels

0:47:34 waleee karlosz: thanks, now I just have to brush up on the gdb-fu to check what ails the gtk-threads of nyxt

0:48:02 stassats g_log is killing it, it should have a message

0:49:08 waleee stassats: success on the lisp side, :INVALID-CODE-OBJECT-AT-PC is not of type FUNCTION

0:49:31 stassats right, i didn't actually test it

0:50:40 waleee definetly more informative than "NIL is not type SB-KERNEL:CODE-COMPONENT" so I count that as a win

0:52:19 stassats why does it want it to be a function

0:52:30 waleee re g_log, there's a log message that it was able to work with before, "GApplication is required of xdg-desktop-portal access in the WebKit sandbox"

0:53:38 waleee * log message that didn't seem to affect nyxt before

0:53:57 stassats that may be from a different instance of g_log

0:55:42 waleee right before erroring out when trying to open an url it prints:

0:55:44 waleee ** (process:203567): ERROR (recursed) **: GApplication is required for xdg-desktop-portal access in the WebKit sandbox.fatal error encountered in SBCL pid 203567 tid 203582:

0:55:47 waleee SIGABRT received.

0:57:07 stassats so, anyway, the problem is in webkit then

0:58:35 waleee looks like it. Thanks for confirming it

1:00:07 stassats i can play further with void foo () {asm("int3");}

1:28:06 stassats i think traps not inside lisp code should just be ignored

1:28:40 stassats although i guess it's nice being able to unwind

7:55:03 _heisig ** NICK heisig