mnsanghvi
mnsanghvi
I'm seeing the same issue on Freebsd 13.1-RELEASE-p2 running on amd64. First, htop information:  What the htop shows:  Output of `systat -vmstat 2`  Here is the output...
Another update on this issue. This keeps happening. Here are some more Backtraces and messages from the `*Messages*` buffer: ```elisp ;; while trying to open up a Lisp file p4-maybe-start-update-statuses:...
I'd love to have 'p4 sync'. Maybe its there and I'm not seeing it, but doing C-s in emacs on p4.el did not bring it up. I am certainly open...
Yes. That is what I was looking for, although `p4-update` works just fine as well. Just out of curiosity where in p4.el is p4-sync ? The only time I see...
Here is the failure for `bclasp` that I get: ``` Starting clasp-boehmprecise-1.0.0-183-g98b564adb-cst ... loading image... Loading/compiling source: /usr/home/mehul/src/clasp/src/lisp/kernel/lsp/direct-calls.lisp Loading/compiling source: /usr/home/mehul/src/clasp/build/boehmprecise/generated/cl-wrappers.lisp Loading/compiling source: /usr/home/mehul/src/clasp/src/lisp/kernel/tag/min-start.lisp Loading/compiling source: /usr/home/mehul/src/clasp/src/lisp/kernel/init.lisp Loading/compiling source: /usr/home/mehul/src/clasp/src/lisp/kernel/tag/after-init.lisp...
> **System details** > > ```shell > % dmesg | grep -Ei 'cpu|memo' > CPU: AMD PRO A10-8700B R6, 10 Compute Cores 4C+6G (1796.66-MHz K8-class CPU) > real memory =...
Contents of `/usr/src/lib/libthr/thread/thr_mutex.c` that is causing the issue at the first `PANIC` on line 4. ```c mutex_assert_not_owned(struct pthread *curthread __unused, struct pthread_mutex *m __unused) { #if defined(_PTHREADS_INVARIANTS) if (__predict_false(m->m_qe.tqe_prev !=...
Yes, I'm familiar with `gdb` though haven't used it in a while.