Bug#961725: libopenblas-dev: On some cpus, openmp and pthread dead-lock

Dirk Eddelbuettel edd at debian.org
Thu May 28 16:55:46 BST 2020


On 28 May 2020 at 16:55, Sébastien Villemot wrote:
| Hi Dirk,
| 
| Le jeudi 28 mai 2020 à 07:07 -0500, Dirk Eddelbuettel a écrit :
| > Package: libopenblas-dev
| > Version: 0.3.8+ds-1
| > Severity: serious
| 
| > In short, when libopenblas-dev is installed (as e.g. from r-base-dev as a
| > dependency from libblas-dev, liblapack-dev) then
| > 
| >     libopenblas0-pthread
| > 
| > is installed first via our depends ranking as libopenblas-pthread-dev comes
| > first.
| > 
| > This has served us well over the years but can exhibit a bug which I for
| > example saw with (Ubuntun's) 0.3.8+ds-1 package. Running a simple
| > 
| >     example(solve)
| > 
| > in R hangs in an unsuspendable session (ie no Ctrl-C, kill is needed).
| > Simplest test is on the command-line via
| > 
| >     $ Rscript -e 'example(solve)'
| > 
| > Removing libopenbkas0-pthread and installing libopenblas-openmp-dev helps. As
| > does a manual reordering of the alternatives.
| > 
| > This bug is reproducible on my system with a i7-8700k.
| 
| I’ve tried to reproduce it on my i7-8700K, without success. I used a
| clean sid chroot (with r-base 4.0.0-3 and openblas 0.3.9+ds-1).
| Downgrading to openblas 0.3.8+ds-1 (which is the version against which
| you reported the bug) does not change anything.
| 
| So it’s not clear that this bug is tied to a specific hardware. At
| least, a given CPU model is not a guarantee of reproducibility.

Darn.  What next?  Shall we compare environment variables (I don't set too
many and can't think of one that does it.)

Or shall we be speculative and try a 'private' package with the two defines
Mo suggested to see if that helps on my side?

Did the Parisian student ever contact you?

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org



More information about the debian-science-maintainers mailing list