bug#28211: Stack marking issue in multi-threaded code, 2020 edition

On Thu 12 Mar 2020 22:59, Ludovic Courtès writes: > I think I’ve found another race condition involving stack marking, as a > followup to (this time on > 3.0.1+, but the code is almost the same.) > > ‘abort_to_prompt’ does this: > > fp = vp->stack_top -

bug#39646: GNOME desktop experience regressions

Hello all, In January I upgraded my machine after a long time not doing so. Mostly things went fine, which is great! Some things didn't, though, so I started looking. One is that if I Alt-F2 and then run "~/Documents", I expect Nautilus to open the folder. Instead Baobab does. This is because

bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism

On Fri 20 Dec 2019 22:08, Ricardo Wurmus writes: > zimoun writes: > >> - I propose the name "guix shell" > > This is not a bad idea, especially considering that “guix environment” > was meant to get shebang support, so that you could use it as the > interpreter in a script that handles the envi

bug#27476: libguile/memoize.c is not thread safe, so syntax parameter expansion is not thread-safe

Hi! On Wed 06 Feb 2019 15:48, Ludovic Courtès writes: > I drew the conclusion that our syntax parameter is redefined when we > compile or when we load (guix monads), so there’s a chance that we get > to see the wrong value when we expand (guix monads) (I’m not entirely > sure about the exact seq

bug#31925: 'guix substitutes' sometimes hangs on glibc 2.27

On Thu 05 Jul 2018 14:27, l...@gnu.org (Ludovic Courtès) writes: > Hello, > > Andy Wingo skribis: > >> The signal thread is a possibility though in that case you'd get a >> warning; the signal-handling thread appears in scm_all_threads. Do you >> see a war

bug#31925: 'guix substitutes' sometimes hangs on glibc 2.27

Hi, On Thu 05 Jul 2018 12:05, Mark H Weaver writes: > However, it's also the case that libgc uses 'pthread_atfork' (where > available) to arrange to grab the GC allocation as well as the "mark > locks" in the case where parallel marking is enabled. See > fork_prepare_proc, fork_parent_proc, and

bug#31925: 'guix substitutes' sometimes hangs on glibc 2.27

Hi! On Thu 05 Jul 2018 05:33, Mark H Weaver writes: >> One problem I’ve noticed is that the child process that >> ‘call-with-decompressed-port’ spawns would be stuck trying to get the >> allocation lock: >> >> So it seems quite clear that the thing has the alloc lock taken. I >> suppose this ca

bug#28211: Stack marking issue in multi-threaded code

Hi! First of all, I said on IRC but: ___nice___ debugging, Ludo! An impressive show of persistence. Thanks Mark also for insightful comments! On Sat 30 Jun 2018 23:49, Mark H Weaver writes: >>> I should say that I'm not confident that _either_ of these proposed >>> solutions will adequately a

bug#28211: Grafting code triggers GC/thread-safety issue on Guile 2.2.2

On Thu 10 May 2018 08:50, Mark H Weaver writes: > Andy Wingo writes: > >> On Wed 09 May 2018 02:32, Mark H Weaver writes: >> >>> However, I think it's _far_ more likely that the NULL argument on the >>> stack was copied from memory shared by m

bug#27476: libguile/memoize.c is not thread safe, so syntax parameter expansion is not thread-safe

On Wed 09 May 2018 11:23, l...@gnu.org (Ludovic Courtès) writes: >> Is the memoization you are referring to the "set!" in the "lazy" form in >> ice-9/eval.scm ? Or something else? FWIW I would not think the "set!" >> could be the issue, at least on x86, but who knows. > > Actually I’m not sure e

bug#28211: Grafting code triggers GC/thread-safety issue on Guile 2.2.2

On Wed 09 May 2018 02:32, Mark H Weaver writes: > However, I think it's _far_ more likely that the NULL argument on the > stack was copied from memory shared by multiple threads without proper > thread synchronization. I think this is unlikely on x86 given its total-store-ordering memory model.

bug#27476: libguile/memoize.c is not thread safe, so syntax parameter expansion is not thread-safe

Hi, On Mon 30 Apr 2018 23:39, l...@gnu.org (Ludovic Courtès) writes: > So the problem, AIUI, is that psyntax evaluates syntax parameters using > ‘primitive-eval’ (via ‘eval-local-transformer’), but memoization in > (ice-9 eval) is not thread-safe, hence the random crashes. Sorry I've been a bit

bug#27476: guix pull fails on powerful server

On Fri 22 Sep 2017 16:10, l...@gnu.org (Ludovic Courtès) writes: > Hi Ricardo, > > Ricardo Wurmus skribis: > >> The following derivation will be built: >>/gnu/store/yvyfkns3w3vm7ynwbr7mvxcmin4gd2a0-guix-latest.drv >> copying and compiling to >> '/gnu/store/7m52dkr98nhwgpsx20mmpwyw2yzj58d3-gu

bug#26594: guix pull --bootstrap does not work

I did a "guix pull" and it carped that there was a 404 for the bash-4.4A NAR, and suggested --fallback. But there is no --fallback argument to guix pull for some reason. OK. There's a --bootstrap argument but although it can install the deps, it can't pull, because: In unknown file: ?: 0

bug#25775: Attempts to fix bootstrap Guile bug

Hi, It seems that this bug is related to the introduction of url-fetch/reset-patch-level. It takes a #:guile kwarg but defaults to #f; if not given #:guile, that #f propagates through instead of a package object. So one fix is here: diff --git a/gnu/packages/bootstrap.scm b/gnu/packages/boots

bug#22693: `guix refresh -u` updates other packages with same version

On Mon 04 Apr 2016 12:20, iyzs...@member.fsf.org (宋文武) writes: > How to fix this? > > The procedure is ‘update-package-source’ in (guix upstream). > it find the file, then use ‘substitute’ to replace the version and > hash. ‘substitute’ works line-by-line, it can’t match mutiple lines. > > I try:

bug#22186: Use {C,CPLUS,OBJC}_INCLUDE_PATH instead of CPATH

Thank you for thinking about this :) On Thu 17 Dec 2015 22:43, l...@gnu.org (Ludovic Courtès) writes: > Andy Wingo skribis: > >> We should be using C_INCLUDE_PATH instead of CPATH, to mark system >> headers as system headers. Except that C_INCLUDE_PATH only works for >&g

bug#22186: Use {C,CPLUS,OBJC}_INCLUDE_PATH instead of CPATH

On Wed 16 Dec 2015 20:18, Efraim Flashner writes: >> We should be using C_INCLUDE_PATH instead of CPATH, to mark system >> headers as system headers. Except that C_INCLUDE_PATH only works for >> C, so we need to also set CPLUS_INCLUDE_PATH and OBJC_INCLUDE_PATH. >> And that's the proposal of thi

bug#22186: Use {C,CPLUS,OBJC}_INCLUDE_PATH instead of CPATH

Hi, I am building GDB from git, because I want to hack on GDB. I have a few build-related things in my profile, including GCC. I enter an environment for GDB like this: guix environment gdb --ad-hoc flex autoconf-2.64 Cool. Very good. I build: mkdir +2.0 cd +2.0 ../configure --prefi