Please apply libgomp patch to GCC for Hardy Heron

I can confirm that this bug exists; using f2py with a Fortran code linked with libgomp exposes the bug.

I fixed by adding the attached dpatch file to the source .dep (apt-get source gcc-4.2) patch directory, including the file in rules.patch, and building a new set of packages from source. I am not sure if this works universally, but the dpatch is based on the gcc patch posted above by James, so it should work in general. This patch is supposed to be applied for gcc 4.3.0, but this at least fixes the bug for gcc 4.2.3.

Josh Finkbeiner

Accepted into -proposed, please test and give feedback here. Please see https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Excellent! I should be able to test over the weekend.

     James

Same error during testing:

ImportError: /usr/lib/libgomp.so.1: cannot allocate memory in static TLS block

To verify that I have the correct libgomp from hardy-proposed, please check this timestamp:

ls -ltr /usr/lib/libgomp.so.1.0.0
-rw-r--r-- 1 root root 24084 2008-09-10 14:08 /usr/lib/libgomp.so.1.0.0

     James

I've also got the error:

/usr/lib/libgomp.so.1: cannot allocate memory in static TLS block

with proposed hardy updates enabled:

ls -ltr /usr/lib/libgomp.so.1.0.0
-rw-r--r-- 1 root root 30024 2008-09-10 21:30 /usr/lib/libgomp.so.1.0.0

If I can provide any additional information I will. FYI, when compiled with icc the program works fine.

This bug was fixed in the package gcc-4.2 - 4.2.4-3ubuntu3

---------------
gcc-4.2 (4.2.4-3ubuntu3) intrepid; urgency=low

  * Update to SVN 20081008 from the ubuntu/gcc-4_2-branch.
    - PR middle-end/37731 (wrong code), PR middle-end/36575 (wrong code),
      PR rtl-optimization/37544 (wrong code), PR target/37101 (wrong code),
      PR middle-end/35432 (ice-on-valid).
    - PR libgcj/8995 (race conditions in interpreter), PR libgcj/31890
      out-of-sync javaprims.h regenerated).
    - Fix naming of bridge targets in gjavah (wrong header generation).
  * Fix PR c/35437 (ice-on-invalid), taken from the gcc-4.3 branch.
    LP: #251744.
  * gij/gcj: Don't remove alternatives on upgrade. Addresses: #479950.
  * Fix PR libgomp/28432. LP: #235070.
  * debian/rules.conf: Filter empty '[]' and '!none' in control file (Andrea
    Gasparini). LP: #268132.

 -- Matthias Klose <email address hidden> Wed, 08 Oct 2008 13:48:28 +0200

I am using Ubuntu 8.04, amd64. I just encountered the exact same bug discussed above. I have an OpenMP code which I compile as a shared library with both ICC and GCC. I load these libraries using ctypes in Python.
When compiled with ICC it works fine, but with GCC I get the error message: OSError: /usr/lib/libgomp.so.1: cannot allocate memory in static TLS block

I have hardy-proposed enabled, yet the 4.2.4-3ubuntu3 package, which fixes this bug, does not seem to be available in the repository.

The only versions that I see are:
4.2.4-1ubuntu3 (hardy-updates)
4.2.3-2ubuntu7 (hardy)

I have 4.2.4-1ubuntu3. I see that 4.2.4-3ubuntu3 is available in 8.10, but upgrading to a non-LTS release is not possible.

Thanks,
Andrew

Andrew,

You can request the update to be backported to hardy through a bug report. There are example reports at https://launchpad.net/hardy-backports/+filebug . I can take care of your backport request once you make the report if you send me a message with the bug number included.

Thank you for your help in making Ubuntu better

Hi,

This bug affects ImageMagic which is used in the ASP services we run. This has caused us to be unable to upgrade to Hardy.

Fixing this bug is critical.

What can we do to get a fixed package into Hardy as soon as possible?

Regards,
Keean.

Keean

Compiling ImageMagick with --disable-openmp was a workaround for me (ImageMagick 6.4.7-8).

I agree with the above posters that a fixed package would really help...

Thanks

Okay, the request to back port the compiler has been rejected. I didn't realise there was a compile time fix for Image Magick.

What is being done to progress this bug? Should we open new bug reports to get fixed packages for each affected application?

The patch as applied was as follows:

--- libgomp/configure.tgt 2007/05/04 19:20:28 124444
+++ libgomp/configure.tgt 2007/05/04 19:21:18 124445
@@ -11,14 +11,11 @@
 # XLDFLAGS Add extra link flags to use.

 # Optimize TLS usage by avoiding the overhead of dynamic allocation.
-# This does require that the library be present during process
-# startup, so mark the library as not to be dlopened.
 if test $have_tls = yes ; then
   case "${target}" in

     *-*-linux*)
       XCFLAGS="${XCFLAGS} -ftls-model=initial-exec"
- XLDFLAGS="${XLDFLAGS} -Wl,-z,nodlopen"
       ;;
   esac
 fi

However, the upstream bug indicates that the XCFLAGS line needs to be removed too. Reopening.

> However, the upstream bug indicates that the XCFLAGS line needs to be removed too.

well, not if you look at the trunk and the 4.3 branch. Unsure if the proposed solution is the correct one, or if something else is missing. However removing this optimization seems to be safe.

This is the error produced whn trying to compile PerlMagick.

Can't load '/root/.cpan/build/PerlMagick-6.40-0f_k64/blib/arch/auto/Image/Magick/Magick.so' for module Image::Magick: /usr/lib/libgomp.so.1: cannot allocate memory in static TLS block at /usr/lib/perl/5.8/DynaLoader.pm line 225.
 at t/blob.t line 20
Compilation failed in require at t/blob.t line 20.

Matthias, what does the other change do?

+ * Update backport for PR28322 (Gunther Nikl). Emit warnings instead
+ of errors for unknown -Wno-* options.

Accepted into intrepid-proposed; please test and give feedback here. Please see https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

I mean hardy-proposed, sorry.

Did anyone test this?

This has still not been published to hardy-updates despite being made available for testing 4 months ago. Is anyone able to confirm whether 4.2.4-1ubuntu4 fixes this problem? Is there a simple test case one can use to check this?

I'm not sure if a simple test case exists - this bugs seems to manifest in fairly unusual scenarios. We experienced this while creating "mex" modules for Matlab.

Using this trivial example (test.c):
#include <omp.h>
#include "mex.h"

void mexFunction( int nlhs, mxArray *plhs[],
                  int nrhs, const mxArray *prhs[] )
{

int nthreads, tid;
#pragma omp parallel private(nthreads, tid)
  {
  tid = omp_get_thread_num();
  printf("Hello World from thread = %d\n", tid);

  if (tid == 0)
    {
    nthreads = omp_get_num_threads();
    printf("Number of threads = %d\n", nthreads);
    }
  }
}

And compiling with:
gcc -fopenmp -fPIC -o test.mexa64 -shared -I/opt/matlab/extern/include test.c

We get the following error:
$ export OMP_NUM_THREADS=4; echo "test" | matlab -nodisplay
>> ??? Invalid MEX-file
'/home/user/testmex/test.mexa64':
/usr/lib/libgomp.so.1: cannot allocate memory in static TLS block.

This is with gcc-4.2-base and libgomp1 4.2.4-1ubuntu3

After upgrading to gcc-4.2-base and libgomp1 4.2.4-1ubuntu4, the code works properly:

$ export OMP_NUM_THREADS=4; echo "test" | matlab -nodisplay
>> Hello World from thread = 1
Hello World from thread = 3
Hello World from thread = 2
Hello World from thread = 0
Number of threads = 4

So, at least for this specific case of a Matlab mex module dynamically linked to libgomp, 4.2.4-1ubuntu4 fixes the problem.

I hope this helps...

thanks, that's the confirmation we were looking for. Publishing to hardy-updates.

This bug was fixed in the package gcc-4.2 - 4.2.4-1ubuntu4

---------------
gcc-4.2 (4.2.4-1ubuntu4) hardy-proposed; urgency=low

  * Fix PR libgomp/28432. LP: #235070, using the patch in intrepid.
  * Update backport for PR28322 (Gunther Nikl). Emit warnings instead
    of errors for unknown -Wno-* options.

 -- Matthias Klose <email address hidden> Mon, 19 Jan 2009 19:41:43 +0100