EXC_BAD_ACCESS in CarpetIOASCII

Issue #177 closed
Ian Hinder created an issue

I am trying to run a minimal parameter file for testing purposes (attached). Cactus gets as far as printing the iteration 0 info line and then appears to hang. When I run in a debugger, it reports:

Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: 13 at address: 0x0000000000000000 0x0000000100b858b7 in CarpetIOASCII::WriteASCII<0> (os=@0x7fff5fbfc5e0, gfdatas={<std::_Vector_base<const gdata , std::allocator<const gdata > >> = {_M_impl = {<allocator<const gdata >> = {<__gnu_cxx::new_allocator<const gdata >> = {<No data fields>}, <No data fields>}, _M_start = 0x109f0ea10, _M_finish = 0x109f0eab8, _M_end_of_storage = 0x109f0eab8}}, <No data fields>}, gfext=@0x7fff5fbfc960, vi=0, time=0, org=@0x7fff5fbfcafc, dirs=@0x7fff5fbfd150, rl=0, ml=0, m=0, c=0, tl=0, coord_time=0, coord_lower=@0x7fff5fbfc9d8, coord_upper=@0x7fff5fbfc9f0) at ioascii.cc:1378 1378 switch (vartype) { (gdb) bt #0 0x0000000100b858b7 in CarpetIOASCII::WriteASCII<0> (os=@0x7fff5fbfc5e0, gfdatas={<std::_Vector_base<const gdata , std::allocator<const gdata > >> = {_M_impl = {<allocator<const gdata >> = {<__gnu_cxx::new_allocator<const gdata >> = {<No data fields>}, <No data fields>}, _M_start = 0x109f0ea10, _M_finish = 0x109f0eab8, _M_end_of_storage = 0x109f0eab8}}, <No data fields>}, gfext=@0x7fff5fbfc960, vi=0, time=0, org=@0x7fff5fbfcafc, dirs=@0x7fff5fbfd150, rl=0, ml=0, m=0, c=0, tl=0, coord_time=0, coord_lower=@0x7fff5fbfc9d8, coord_upper=@0x7fff5fbfc9f0) at ioascii.cc:1378 #1 0x0000000100b5b7ee in CarpetIOASCII::IOASCII<0>::OutputDirection (cctkGH=0x109f073f0, vindex=0, alias={_M_dataplus = {<allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0x10a06c1c8 "carpet::timing"}}, basefilename={_M_dataplus = {<allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0x10a06ba68 "minimal/carpet::timing"}}, dirs=@0x7fff5fbfd150, is_new_file=true, truncate_file=true) at ioascii.cc:610 #2 0x0000000100b554c4 in CarpetIOASCII::IOASCII<0>::OutputVarAs (cctkGH=0x109f073f0, varname=0x10a06c170 "CARPET::physical_time_per_hour", alias=0x10a06be00 "carpet::timing") at ioascii.cc:480 #3 0x0000000100b57370 in CarpetIOASCII::IOASCII<0>::TriggerOutput (cctkGH=0x109f073f0, vindex=0) at ioascii.cc:359 #4 0x0000000100b542b7 in CarpetIOASCII::IOASCII<0>::OutputGH (cctkGH=0x109f073f0) at ioascii.cc:239 #5 0x000000010329a006 in Carpet::OutputGH (cctkGH=0x109f073f0) at OutputGH.cc:55 #6 0x0000000103293b25 in Carpet::OutputGH (where=0x104c70f3c "Initialise::CallAnalysis", cctkGH=0x109f073f0) at Initialise.cc:1382 #7 0x000000010328d432 in Carpet::CallAnalysis (cctkGH=0x109f073f0) at Initialise.cc:530 #8 0x00000001032892d4 in Carpet::Initialise (fc=0x7fff5fbfe2b0) at Initialise.cc:118 #9 0x000000010005806a in main (argc=4, argv=0x7fff5fbfe318) at flesh.cc:80

I do not see how this line "switch(vartype)" where vartype is declared on the stack, could lead to this error. This configuration has been rebuilt with -O0 (Intel compiler) and debugging enabled.

This is with the current production (Git) version of Carpet running on Mac OS 10.6.5. The code is compiled as 64 bit. This parameter file has worked in the past, though with 32 bit on Mac OS 10.5.

Keyword:

Comments (10)

  1. Erik Schnetter
    • removed comment

    I do not see what could be wrong in this case.

    I have seen strange segmentation faults in the past, and I believe they are connected with inheritance and virtual methods. A few lines further down is a cast from a parent class (gdata*) to a child class (data<T>*). I believe this is legal in C++, but there may be a subtlety in the C++ standard that I am missing, or there may be a compiler error.

    Can you try with a different compiler or a different compiler version?

    Which compiler and version are you using? What options are you using?

  2. Ian Hinder reporter
    • removed comment

    I have tried with GCC and everything works fine. I have cut down my Intel optionlist and am attaching it. It appears to be essentially the same as redshift-intel from simfactory. I have tried disabling optimisation and enabling debugging, and neither of these help.

  3. Erik Schnetter
    • removed comment

    Can you try with a different version of the Intel compiler?

    Can you output (after casting to void*, and using printf's %p) the values of gfdata and (const data<T>*)gfdata? Can you output what T is in this case, or what specific_cactus_type returns? Can you output gfdata->varindex and find out what Cactus variable this is?

  4. Roland Haas
    • removed comment

    Does this still apply? It refers to the git version of Carpet being the current one?

  5. Ian Hinder reporter
    • removed comment

    I don't know. I don't use the Intel compiler on my Mac any more. I suspect it was down to a bug in the Intel compiler for Mac OS, but this is just conjecture. Someone with the Intel compiler on Mac OS should try to reproduce the problem. I wouldn't like to close the ticket if the problem still exists.

  6. Roland Haas

    My guess would be that this is related to git hash eb2c2b94 "CarpetIOASCII: adapt to gdata::copy_from being static" of carpet and git hash 6537e215 "CarpetLib: make gdata transfer functions static functions" of carpet. Before those Carpet/CarpetLib would use a NULL pointer to call (non-virtual) member functions that it “knew” would not actually access member variables due to arguments in the call. This was never quite legal (this must not be NULL and must always (even in the constructor) point to a valid region of memory).
    Essentially the compiler is free to optimize things like:

    int foo::bar(int a) {
      if(a)
        return 0;
      int b = this->c;
      return b;
    }
    

    to

    int foo::bar(int a) {
      int b = this->c;
      if(a)
        return 0;
      return b;
    }
    

    since the standard guarantees that this is valid.

  7. Log in to comment