[ET Trac] [Einstein Toolkit] #1816: segfaults on 64bit systems when build with c99

Einstein Toolkit trac-noreply at einsteintoolkit.org
Fri Sep 18 12:36:24 CDT 2015


#1816: segfaults on 64bit systems when build with c99
--------------------------------+-------------------------------------------
 Reporter:  physik@…            |       Owner:            
     Type:  defect              |      Status:  new       
 Priority:  unset               |   Milestone:            
Component:  Cactus              |     Version:  ET_2014_05
 Keywords:                      |  
--------------------------------+-------------------------------------------
 I recently encountered a segfault in ScheduleInterface.c, more precisely
 in the function

 static int CCTKi_ScheduleCallFunction(void *function,
                                       t_attribute *attribute,
                                       t_sched_data *data)
 {
   /* find the timer for this function and this schedule bin */
   t_timer *timer = attribute->timers;
   while (timer && strcmp(timer->schedule_bin, data->schedule_bin))
   {
     timer = timer->next;
   }

 Running in the debugger revealed that timer->schedule_bin pointed to an
 invalid address. Curiously, it had the top 33 (33 not a typo) bits all
 set. Taking the lowest 32 bits gave a valid address which pointed to a
 reasonable string "CCTK_INITIAL". This suggests a 32/64 bit issue. The
 pointer timer->schedule_bin seems to be initialized in the same function
 using strdup:

 timer->schedule_bin = strdup (where);

 strdup is not part of the c99 standard, but only Posix. Compiling with gcc
 --std=c99 means it is not defined in <string.h>. This means the compiler
 treats the occurrence of strdup as an implicit function declaration, and
 assumes it returns int.
 Thus, it will do an implicit conversion of the result from int to char*.
 If the highest bit of the int was set, this resulted in a 64 bit pointer
 with all 32 high bits set (I checked with a small test code).
 When the address returned by the actual strdup code linked from glibc has
 the top 33 bits zero, the conversion yields the correct results.
 Therefore, the problem is hard to reproduce, it only occurred with a test
 case almost exhausting my workstations memory, but frustratingly not small
 tests.

 After this, I also found compiler warnings for ScheduleInterface.c of the
 type

 implicit declaration of function ‘strdup’ [-Wimplicit-function-
 declaration]
 and
 assignment makes pointer from integer without a cast [-Wint-conversion]

 Switching from --std=c99 to --std=gnu99 fixed the problem for now.
 However, this is a bug that might affect many users since the code
 compiles with --std=c99 and the compiler warnings are hidden within the
 thousands of other compiler warnings the ET code generates.

 Also, a quick grep revealed many occurrences of strdup, although some of
 them where redefined as Util_Strdup. The rest might lead to segfaults on
 64 bit systems with std=c99.

 My findings concern the Wheeler release, I haven't had time to check the
 development version.

-- 
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1816>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit


More information about the Trac mailing list