[LLVMdev] Bug in DragonEgg or LLVM

sabaliauskas g. (gs5g08) gs5g08 at ecs.soton.ac.uk
Wed Nov 10 10:22:38 PST 2010


The following code using OpenMP pragmas , when compiled with gcc 4.5 + LLVM 2.8 + DragonEgg 2.8 and ran, produces segmentation fault.

//-----------------------------------------------------------
#define LOOPCOUNT 10000

int main()
{
  int bit_and = 1;
  int logics[LOOPCOUNT];
  int i;

  for (i = 0; i < LOOPCOUNT; ++i)
  {
      logics[i] = 1;
  }

#pragma omp parallel for schedule(dynamic,1) reduction(&:bit_and)
  for (i = 0; i < LOOPCOUNT; ++i)
  {
      bit_and = (bit_and & logics[i]);
  }
}
//-----------------------------------------------------------

Examination with valgrind produces these results:

==5064== Thread 2:
==5064== Use of uninitialised value of size 8
==5064==    at 0x40074E: main.omp_fn.0 (in test113)
==5064==    by 0x4C44FE1: gomp_thread_start (team.c:115)
==5064==    by 0x3A1EA07760: start_thread (in /lib64/libpthread-2.12.1.so)
==5064==    by 0x3A1E2E14FC: clone (in /lib64/libc-2.12.1.so)
==5064== 
==5064== Invalid read of size 4
==5064==    at 0x40074E: main.omp_fn.0 (in test113)
==5064==    by 0x4C44FE1: gomp_thread_start (team.c:115)
==5064==    by 0x3A1EA07760: start_thread (in /lib64/libpthread-2.12.1.so)
==5064==    by 0x3A1E2E14FC: clone (in /lib64/libc-2.12.1.so)
==5064==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==5064== 
==5064== 
==5064== Process terminating with default action of signal 11 (SIGSEGV)
==5064==  Access not within mapped region at address 0x0
==5064==    at 0x40074E: main.omp_fn.0 (in test113)
==5064==    by 0x4C44FE1: gomp_thread_start (team.c:115)
==5064==    by 0x3A1EA07760: start_thread (in /lib64/libpthread-2.12.1.so)
==5064==    by 0x3A1E2E14FC: clone (in /lib64/libc-2.12.1.so)


As I understand the segmentation fault arises because in the file  "team.c" in function "gomp_thread_start" the program tries to read memory through an uninitialized pointer. 

Has any body encountered this problem before or has any ideas how to fix it or knows which particular part of DragonEgg or LLVM could be causing this issue?
I would be very grateful for any help provided.  





More information about the llvm-dev mailing list