freenode/#clasp - IRC Chatlog
Search
7:55:56
kpoeck
::notify drmeister regarding signal handling. We made some changes, so that most signals are handeld and can even have handlers written in lisp
7:56:54
kpoeck
::notity drmeister kill -s SIGSEGV <pid> -> Condition of type: SEGMENTATION-VIOLATION in clasp
7:56:54
Colleen
Unknown command. Possible matches: notify, 8, set, mop, get, login, roll, say, uptime, grant,
7:57:30
kpoeck
::notify drmeister kill -s SIGSEGV <pid> -> Condition of type: SEGMENTATION-VIOLATION in clasp
9:13:17
kpoeck
now it is nicely passed to lisp, or you can handle it, even with a handler written in lisp
9:41:17
frgo
kpoeck: Here: https://github.com/dg1sbg/sighandling/blob/master/sighandling/main.cc#L467 I made a first step at setting up signal handling for clasp. It shows the necessary steps.
9:44:17
kpoeck
oops that code might be overlapping with https://github.com/clasp-developers/clasp/blob/master/src/gctools/interrupt.cc#L370
12:13:44
Bike
we had sort of a vestigial use of sigaltstack before. the sigsegv handler had SA_ONSTACK but we didn't actually allocate a stack for it
12:15:07
Bike
i'm worried an alt stack will screw up nonlocal exiting from the signal handler, but hey - we can't do that anyway
13:14:32
Bike
you're right about boot-bitcode-pathnames, but cmpbundle might be used for some kind of special build drmeister does, so i dunno
13:34:22
kpoeck
I adapted the metering provided with slime to work with clasp. I also wanted to drop the use of function in the package si/core. Will make a pr to slime with all together. Hope drmeister can review all together
13:34:37
Colleen
drmeister: kpoeck said 5 hours, 38 minutes ago: regarding signal handling. We made some changes, so that most signals are handeld and can even have handlers written in lisp
13:34:37
Colleen
drmeister: kpoeck said 5 hours, 37 minutes ago: kill -s SIGSEGV <pid> -> Condition of type: SEGMENTATION-VIOLATION in clasp
13:34:37
Colleen
drmeister: kpoeck said 5 hours, 33 minutes ago: after (ext:default-interrupt :sigsegv) a sigsegv terminates clasp
13:34:37
Colleen
drmeister: frgo said 4 hours, 24 minutes ago: I think kpoeck said it all re signals.
13:37:35
drmeister
When a thread is created (or the main process is registered as a thread) the system calculates an address at the bottom of the stack that is memory page aligned and calls 'mprotect' to set a few pages to PROT_NONE
13:39:15
drmeister
I couldn't get the segmentation fault handler to catch anything last night - very frustrating.
13:40:02
kpoeck
I did change some things regarding handlers, but I believe sigsegv handling is as before
13:40:31
drmeister
Bike: cmpbundle is used by the system to figure out directories that clasp needs to run. It needs to handle development directory layouts and production directory layouts.
13:42:10
kpoeck
the question was whether https://github.com/clasp-developers/clasp/blob/master/src/lisp/kernel/cmp/cmpbundle.lsp#L411 is used anywhere or we can delete it
14:03:52
drmeister
I'm pretty sure it's not being called from there - but the buildbot will catch it if it is.
14:04:16
Bike
is there some way we could stress test cmpbundle functions that may not be used during build?
14:07:25
kpoeck
some functions are clearly only used by asdf, so testing needs to include compiling quicklisp systems
14:08:23
drmeister
The buildbot builds the entire cando system with all of its quicklisp and jupyterlab.
14:08:52
drmeister
So if you are worried about taking something out. Do the checks you did and then take it out and then check the buildbot in a couple of hours.
14:09:13
drmeister
The way to build all the cando quicklisp systems is to just start cando. It happens automatically.
14:10:14
kpoeck
Here is my testbed for cando libraries: https://gist.github.com/kpoeck/153c2b05ca87c7f125524ef561a92d9e
14:15:56
kpoeck
drmeister some days ago you asked about qtools wxwidget and don't know what different frameworks
14:17:23
kpoeck
I compiled wxwidgets on macosx, seems to work fine, but clearly is not used often (e.g. the provided xcode project was several years old and did not work)
16:18:46
drmeister
Bike: I'll point this out to karlosz as well. The latest build time on the buildbot increased by 16 min. From 2:20 to 2:36.
16:21:57
yitzi
drmeister: Not sure if you saw it before, but I put some format commands in the various installer-path-part methods and it looks like the :prefix specialization gets called even when :root is specified.
16:21:59
drmeister
Last night I was using: kill SIGSEGV <pid> and that just causes clasp to terminate.
16:23:42
yitzi
when you call (installer-path-part inst :prefix) it calls in (installer-path-part inst :root) in its body
16:24:00
drmeister
yitzi: I'm working on code that would trap infinite recursive loops by putting a guard page at the bottom of the stack that will let us get a backtrace if they happen.
16:25:21
yitzi
continuing...the call to (installer-path-part inst :root) doesn't actually go the right method instead it ends up going to (installer-path-part inst :prefix) which is what causes the infinite recursion
16:26:25
drmeister
I can't get a backtrace yet to identify the function that is calling itself recursively.
16:30:23
kpoeck
drmeister I believe kill SIGSEGV <pid> sends sigterm to the process, so I believe the error is yours
17:02:39
yitzi
drmeister: of the code sample in the PR https://github.com/yitzchak/common-lisp-jupyter/pull/44#issuecomment-634242652
17:04:27
yitzi
You can see the issue if you put (format t "installer-path-part :prefix ~A~%" part) after line 67 and (format t "installer-path-part :prefix ~A~%" type) after line 87
17:05:09
yitzi
drmeister: sorry meant ... format t "installer-path-part :prefix ~A~%" part) after line 67 and (format t "installer-path-part :root ~A~%" type) after line 87
17:06:47
drmeister
I just don't see another call to (installer-path-part ... :prefix). I don't have this code up at the moment to work on. I went off on a tangent to catch infinite recursion calls in general so we can get backtraces.
17:08:50
drmeister
Right - but between line 76 and 99 - there is no call to installer-path-part that would cause recursion.
17:09:15
drmeister
I don't see (installer-part-path instance :prefix) that would cause the recursion.
17:09:45
drmeister
So there isn't a bug in your code that's causing this - it's something in the generated code?
17:10:49
yitzi
Correct. The call (installer-path-part instance :root) doesn't go to right place. It goes right back to (installer-path-part instance :prefix)
17:13:24
drmeister
Does anyone know what signal I'm supposed to get on macOS if you touch PROT_NONE memory?
17:14:23
Bike
could you do (compute-applicable-methods #'installer-path-part (list some-instance :prefix)) and with :root? that might just be argument precedence order.
17:14:53
Bike
a lot of these methods specialize on the second argument but not all of them, so it could just be the methods not being ordered like you expect.
17:14:55
drmeister
Maybe the signal handler can't work because the stack at that point is protected.
17:15:28
drmeister
yitzi: Could you: "could you do (compute-applicable-methods #'installer-path-part (list some-instance :prefix)) and with :root? that might just be argument precedence order."
17:15:53
drmeister
yitzi: I'd like to introduce you to Bike - he is working on the clasp compiler and working on generic function dispatch at the moment.
17:16:13
drmeister
Bike: I'd like to introduce you to yitzi. yitzi is working on the jupyterlab code.
17:17:41
drmeister
yitzi: Bike had a suggestion to test the generic function dispatch code in your case.