File: BugList Date: 12/18/2002 ********************* Known Issues/Problems ********************* --------------- I) Introduction --------------- 1. This file contains known issues or problems encountered while performing testing on the MuPC RTS. 2. Some of these problems are program bugs, while some are just information about the MuPC RTS that the user might be need to know. 3. Section II presents a list of bugs and issues about MuPC that cannot quite be categorized as bugs. Section III gives a list of other miscellaneous problems with the EDG frontend and software used to support MuPC. ---------------------------------- II) Bugs/Errors/Problems with MuPC ---------------------------------- II-i) Bugs NOT fixed -------------------- 1. upc_lock_attempt() loops infinitely when number of processes >=8. 2. upc_memput() does not function correctly for large array size (>5000) [error detected in test_string3.c]. 3. upc_memget() failed for large array size [error detected in test_stress_03.c]. 4. upc_memset() not functioning properly for large array size [error detected in test_stress_03.c]. 5. User can allocate more than 8MB of memory. 6. MuPC allows the use of upc_barrier() in between a split-barrier. 7. upc_notify() and upc_wait() do not produce a RTS error when the expressions used in the 2 functions differ. 8. Arguments passed into the main() function of a UPC code during run-time get lost because currently MuPC is not able to process these arguments. Also, the exit value from the main function does not get returned. II-ii) Bugs fixed ----------------- 1. The use of the double data type caused a program to crash. In some instances, it even caused a program to hang. This bug happened because requests generated by gets and puts of double in the internal buffering system were not dequeued properly. 2. Copying block of data from one array to another using upc_memcpy produced erroneous results when the size of the array copied is large. Interestingly, when the size of array was small, this error did not occur. 3. Use of locks together with get operations caused the wrong data to be read from the shared memory. This bug was caused mainly by an error in MuPC's internal buffering system. When locks are used together with get functions, entries (generated by locks) in the buffering system's queue that were not removed appropriately affected other entries (generated by get functions) in the queue. Thus producing the wrong results when the wrong entries were read from the queue. 4. Use of locks together with get operations caused the wrong data to be read from the shared memory. This bug was caused mainly by an error in MuPC's internal buffering system. When locks are used together with get functions, entries (generated by locks) in the buffering system's queue that were not removed appropriately affected other entries (generated by get functions) in the queue. Thus producing the wrong results when the wrong entries were read from the queue. 5. Use of the upc_all_lock_alloc() function in test cases test_locks1.c and test_int_multilocks.c resulted in segmentation fault errors. The errors detected by the two test cases were distinct. In test_locks1.c, the error was caused by the reuse of code from the upc_global_lock_alloc() function. The reuse of code from that function caused some parameters to be set wrongly internally in the upc_all_lock_alloc() function. In test_int_multilocks.c, a variable used for synchronization purposes was not decremented properly, thus causing segmentation faults to happen. 6. The following error message was generated when all threads execute many gets and puts of data concurrently: MPI_Isend: internal MPI error: GER overflow (rank 2, MPI_COMM_WORLD) This problem was caused by MPI's resource limitation. It was fixed by simply adding the -nger flag when executing mpirun. II-iii) Other known issues/problems with MuPC --------------------------------------------- 1. MuPC's dynamic memory allocation functions allocate more memory than requested. For instance, user who wants to allocate 100 integers spread evenly across 4 threads will not get 25 integers on each thread, but instead gets 100 integers on each thread. 2. After allocation of a lock using any of the lock allocation functions, the user has to explicitly initialize the lock using upc_lock_init(). This does not conform to the UPC specifcation as locks are supposed to be implicitly initialized by the RTS after they are allocated. This will pose a problem in the near future as upc_lock_init() will be made obsolete in the next revision of the UPC specification. 3. MuPC does not support the long double data type although MuPC's documentation stated otherwise. Use of this data type would result in compilation error as the functions _UPCRTS_GetSyncLongDouble() and _UPCRTS_PutLongDouble() cannot be resolved. 4. MuPC's main development goal was quick delivery, performance was not a priority. Communication and synchronization among threads cost significantly in MuPC. Thus, MuPC's performance would suffer greatly if a significant number of remote references is issued by each thread. In addition, a slowdown in performance would be noticeable when the number of threads used to run a program exceeds that of the available processors. The slowdown is caused primarily by the extra time needed to perform the finalization phase. 5. The upc_global_exit() function hasn't been implemented on the MuPC RTS yet. 6. The upc_free() and upc_fence() are no-ops in MuPC. upc_fence() can be a no-op because all references in MuPC are currently implemeted as strict. ---------------------------------------- III) Miscellaneous Bugs/Errrors/Problems ---------------------------------------- 1. On the Sun Enterprise, use of a 32-bit EDG frontend binary instead of 64-bit one causes many unusual errors to appear on the Sun Enterprise and Myrinet Cluster. The EDG frontend on the two platforms is 32-bit executable, and thus generates 32-bit code. However, LAM-MPI and MuPC are compiled as 64-bit. As a result, certain operations that used to work properly would behave unusually. For example, in a UPC code (translated by the frontend), the sizeof() of the data type long is evaluated as 4 bytes. However, LAM-MPI and MuPC are expecting sizeof() to be 8 bytes. 2. On the Myrinet Cluster, the current EDG frontend could potentially generate a segmentation fault when translating a piece of UPC code to C. The source of problem has not been identified. 3. On the Sun Enterprise, adding any functions after main() in a UPC program causes program compilation to fail. This problem is caused by a bug in the EDG frontend. Nonetheless, this problem does not seem to surface on the AlphaServer; adding functions after main() does not cause any compilation error. 4. When using the upc_forall loop, the user can usually omit the curly braces {} if threre is only one statement in the body of the loop. However, this is not the case with the EDG frontend. Omission of the curly braces can potentially cause the UPC-to-C code translation performed by the EDG frontend to fail. This problem still prevalent. 5. Sometimes LAM has to be restarted using the lamboot command when a program crashes during testing. Failure to do so will cause subsequent execution of programs to stop working or behave unusually. 6. On the Sun Enterprise, running a new UPC program would kill a UPC program that was executing. Thus, only one UPC program can be run at a time. 7. On the AlphaServer, when multiple programs are run, killing one of the programs might potentially halt the execution of the other programs. This behaviour was observed consistently on the AlphaServer which has LAM-MPI installed. 8. When defining the SIZE of arrays, keep in mind that each thread is only given a pool of 8MB of memory. Thus, defining an integer array of SIZE = 2MB would take up all the memory on one thread.