Re: Bug#953235: vtkplotter: autopkgtest arm64 failure: No module named 'vtkIOFFMPEGPython'
On Mon, May 11, 2020 at 08:31:37AM +0200, Mathieu Malaterre wrote: > On Sun, May 10, 2020 at 10:01 PM Paul Gevers wrote: >... > > On 10-05-2020 15:25, Paul Gevers wrote: > > > I'm running another check on "cannot allocate memory in static TLS > > > block" now, will take a while. > > > > Also for this one, only vtkplotter showed up. > > Did you check #951704 ? This affect python3 package using jemalloc. I wrote earlier: On Thu, May 07, 2020 at 01:16:15PM +0300, Adrian Bunk wrote: >... > #951704 looks like a similar but unrelated problem with jemalloc. >... My current knowledge is: The jemalloc problem is a problem affecting all architectures, that will likely need a fix/workaround in jemalloc. The libgomp problem is a problem only on arm64/ppc64/ppc64el where upstreams seem to finally have agreed where it should be fixed (glibc). cu Adrian
Re: Bug#953235: vtkplotter: autopkgtest arm64 failure: No module named 'vtkIOFFMPEGPython'
On Sun, May 10, 2020 at 10:01 PM Paul Gevers wrote: > > Hi Adrian, > > On 10-05-2020 15:25, Paul Gevers wrote: > > I'm running another check on "cannot allocate memory in static TLS > > block" now, will take a while. > > Also for this one, only vtkplotter showed up. Did you check #951704 ? This affect python3 package using jemalloc. > Paul > -- Mathieu
Re: Bug#953235: vtkplotter: autopkgtest arm64 failure: No module named 'vtkIOFFMPEGPython'
Hi Adrian, On 10-05-2020 15:25, Paul Gevers wrote: > I'm running another check on "cannot allocate memory in static TLS > block" now, will take a while. Also for this one, only vtkplotter showed up. Paul signature.asc Description: OpenPGP digital signature
Re: Bug#953235: vtkplotter: autopkgtest arm64 failure: No module named 'vtkIOFFMPEGPython'
Hi Adrian, On 07-05-2020 12:16, Adrian Bunk wrote: > On Thu, May 07, 2020 at 10:28:33AM +0200, Paul Gevers wrote: >> If we can detect this failure >> mode (and similar ones in the future) we can of course generate hints >> based on this heuristics and have the failures ignored until the >> toolchain issues are fixed. > > A failing arm64 or ppc64el autopkgtest log containing the string > "libgomp.so.1: cannot allocate memory in static TLS block" > is this bug. On ci.d.n I checked for all tests on arm64 the most recent log. The only autopkgtest with the string "/lib/aarch64-linux-gnu/libgomp.so.1: cannot allocate memory in static TLS block" in the logs is vtkplotter. I'm running another check on "cannot allocate memory in static TLS block" now, will take a while. Paul signature.asc Description: OpenPGP digital signature
Re: Bug#953235: vtkplotter: autopkgtest arm64 failure: No module named 'vtkIOFFMPEGPython'
On Thu, May 07, 2020 at 10:28:33AM +0200, Paul Gevers wrote: >... > On 07-05-2020 10:07, Adrian Bunk wrote: > > This is a toolchain problem affecting many packages: > > https://sourceware.org/bugzilla/show_bug.cgi?id=25051 > > Do you have any rough estimate how many? >... Other bugs I can quickly find are #930039 and #945878. AFAIR I have seen maintainers adding workarounds for arm64+ppc64el FTBFS caused by this bug that did not have bugs in the BTS. #951704 looks like a similar but unrelated problem with jemalloc. > Is there any way to predict which packages are effected, Anything loading a plugin that is directly or indirectly linked with libgomp might or might not have this problem. Python C extensions are the most frequent ones. Heavy usage of Python code with C extensions tends to be in the more scientific areas of the archive, I'd guess many of these packages have no users at all on ppc64el or arm64 who would report bugs (Raspbian is armhf). python3-vtkplotter -> python3-vtk7 -> libvtk -> FFmpeg libraries -> libsoxr -> libgomp > or to detect which packages are effected? "import vtk" works, but "import vtkplotter" blows up when importing vtk. This is similar to the two different OpenSSL versions in stretch, where module load order might determine whether Apache segfaults or starts. >... > > Is there a non-manual way to express that the autopkgtest must not run > > on arm64 and powerpc64el? > > There is currently not even a manual way except for marking the test as > skippable and exitting with error code 77 on unsupported architectures. > Mind you, I don't think toolchain issues should be marked at the package > level (but maybe you didn't mean that). vtkplotter: flagged for removal in 6.3 days The big hammer would be to remove the autopkgtest... > If we can detect this failure > mode (and similar ones in the future) we can of course generate hints > based on this heuristics and have the failures ignored until the > toolchain issues are fixed. A failing arm64 or ppc64el autopkgtest log containing the string "libgomp.so.1: cannot allocate memory in static TLS block" is this bug. > Paul cu Adrian
Re: Bug#953235: vtkplotter: autopkgtest arm64 failure: No module named 'vtkIOFFMPEGPython'
Dear Adrian, On 07-05-2020 10:07, Adrian Bunk wrote: > This is a toolchain problem affecting many packages: > https://sourceware.org/bugzilla/show_bug.cgi?id=25051 Do you have any rough estimate how many? Is there any way to predict which packages are effected, or to detect which packages are effected? > There is nothing a binary-all python module can do to fix > architecture-specific toolchain bugs. Ack. > Is there a non-manual way to express that the autopkgtest must not run > on arm64 and powerpc64el? There is currently not even a manual way except for marking the test as skippable and exitting with error code 77 on unsupported architectures. Mind you, I don't think toolchain issues should be marked at the package level (but maybe you didn't mean that). If we can detect this failure mode (and similar ones in the future) we can of course generate hints based on this heuristics and have the failures ignored until the toolchain issues are fixed. Paul signature.asc Description: OpenPGP digital signature
