#1973 Caught sigal 11: SIGSEGV

closed-fixed
z80 port (188)
5
2012-08-14
2012-03-16
Woody
No

1. Sample code attached in sdcc.rar. Please extract it to c:\sdcc, and copy 3 files sdasz80, sdcc.exe and sdcpp.exe to c:\sdcc\bin\ 2.. Command line used: cd C:\SDCC\src, and run mk.bat
3. SDCC version: SDCC : mcs51/gbz80/z80/z180/r2k/ds390/pic16/pic14/TININative/ds400/hc08 3.1.3 #7453 (Mar 15 2012) (MINGW32)
4. Error output:
C:\SDCC\BIN\sdcc sips.c -mz80 -c --std-c99 --max-allocs-per-node 6000 --codeseg CODE5
Caught signal 11: SIGSEGV
sdcpp.exe: fatal error: when writing output to : Invalid argument
..\bin\make: *** [sips.rel] Error 1
Simply run "C:\SDCC\BIN\sdcc sips.c -mz80 -c --std-c99 --max-allocs-per-node 6000 --codeseg CODE5" does not have the problem.

Discussion

  • Woody

    Woody - 2012-03-16
     
  • Woody

    Woody - 2012-03-16

    Just found (by error operation) that if I change c:\sdcc\src\makefile to double --std-c99 option, the signal 11 will not appear. Really interesting!
    C:\SDCC\BIN\sdcc sips.c -mz80 -c --std-c99 --std-c99 --max-allocs-per-node 6000
    --codeseg CODE5

     
  • Borut Ražem

    Borut Ražem - 2012-03-16

    In my case sips.c compiled without crash, but compilation of dtmf.c crashed:

    n:\tmp\bug_3506333\sdcc\BIN\sdcc dtmf.c -mz80 -c --std-c99 --max-allocs-per-node 6000 --codeseg CODE1
    Caught signal 11: SIGSEGV
    ..\bin\make.exe: *** [dtmf.rel] Error 1

    I used the same sdcc version / revision, downloaded from the snapshots web page.

    I think Philipp should take a look what is happening...

    P.S.: it is a very bad practice mixing installed "system" header files, sources and binaries with the ones you wrote. You should put your source and header files in a separate directory and use -I command line option to define the path to your header files.

    Borut

     
  • Woody

    Woody - 2012-03-17

    This is exactly why signal 11 puzzled me so much, different people (among our co-workers) get different crash with same source code.
    In our software, we actually did not use any SDCC include files and lib, only the directory name keep there because of historic reasons. As you can see from bug report 3475656, we provided all needed "system" functions like atoi without using standard lib.
    In other words, after download a snapshot of MINGW32 build, I only change four files: sdasz80, sdcc.exe, sdcpp.exe and sdld.exe.

     
  • Borut Ražem

    Borut Ražem - 2012-03-17

    Just as an additional info for Philipp (maybe Maarten can cofirm this): if I compile sdcc with Visual Studio 2010, sdcc crashes with signal 11 every time -mz80 is used, regardless what kind of sorce code it compiles. For example it crashes with a program as simple as:

    ----8<----
    int x = 0;
    ---->8----

    I suspect that there is an uninitialised variable used somewhere (even that gcc 4.6.1 doesn't complain) or some part of memoy get overwritten.

    > In our software, we actually did not use any SDCC include files and lib...

    I see: the include directory actually contains your version (replacement) of "system" header files. In this case you colud use --nostdlib and --nostdinc to prevent searching in "standard" include and lib directories and define your paths with -I and -L options (this method is used for regression testing). You could also use -isysroot c:\SDCC which defines new system directory, which contains include and lib subdirectories with you version of "system" files (I didn't tes it. If it doesn't work, it means that it is buggy ;-)

    Borut

     
  • Borut Ražem

    Borut Ražem - 2012-03-17

    Maybe I found something (... _M_current’ may be used uninitialized in this function [-Wuninitialized]):

    ccache g++ -pipe -ggdb -O2 -I/home/borutr/local-toto/include -Wall -Wno-parentheses -I/home/borutr/local-toto/include -I. -I.. -I../../sdcc/src/../support/util -I../../sdcc/src -I../../sdcc/src -c -o SDCCnaddr.o ../../sdcc/src/SDCCnaddr.cc
    In file included from ../../sdcc/src/SDCCtree_dec.hpp:53:0,
    from ../../sdcc/src/SDCCnaddr.hpp:33,
    from ../../sdcc/src/SDCCnaddr.cc:22:
    /home/borutr/local-toto/include/boost/graph/detail/adj_list_edge_iterator.hpp: In static member function ‘static void boost::detail::copy_graph_impl<0>::apply(const Graph&, MutableGraph&, CopyVertex, CopyEdge, Orig2CopyVertexIndexMap, IndexMap) [with Graph = boost::adjacency_list<boost::vecS, boost::vecS, boost::directedS>, MutableGraph = boost::adjacency_list<boost::vecS, boost::vecS, boost::undirectedS>, CopyVertex = boost::detail::vertex_copier<boost::adjacency_list<boost::vecS, boost::vecS, boost::directedS>, boost::adjacency_list<boost::vecS, boost::vecS, boost::undirectedS> >, CopyEdge = boost::detail::edge_copier<boost::adjacency_list<boost::vecS, boost::vecS, boost::directedS>, boost::adjacency_list<boost::vecS, boost::vecS, boost::undirectedS> >, IndexMap = boost::vec_adj_list_vertex_id_map<boost::no_property, long unsigned int>, Orig2CopyVertexIndexMap = boost::iterator_property_map<__gnu_cxx::__normal_iterator<long unsigned int*, std::vector<long unsigned int, std::allocator<long unsigned int> > >, boost::vec_adj_list_vertex_id_map<boost::no_property, long unsigned int>, long unsigned int, long unsigned int&>]’:
    /home/borutr/local-toto/include/boost/graph/detail/adj_list_edge_iterator.hpp:70:9: warning: ‘*((void*)(& ei)+48).__gnu_cxx::__normal_iterator<boost::detail::sep_<long unsigned int, boost::no_property>*, std::vector<boost::detail::sep_<long unsigned int, boost::no_property>, std::allocator<boost::detail::sep_<long unsigned int, boost::no_property> > > >::_M_current’ may be used uninitialized in this function [-Wuninitialized]
    /home/borutr/local-toto/include/boost/graph/copy.hpp:122:53: note: ‘*((void*)(& ei)+48).__gnu_cxx::__normal_iterator<boost::detail::sep_<long unsigned int, boost::no_property>*, std::vector<boost::detail::sep_<long unsigned int, boost::no_property>, std::allocator<boost::detail::sep_<long unsigned int, boost::no_property> > > >::_M_current’ was declared here

    Borut

     
  • Philipp Klaus Krause

    Borut, where is that function you found instanciated from?
    However I consider bugs thorugh uninitialized variables in boost rather unlikely. There's many ways to get a segfault, and invoking undefined behaviour by passing the wrong arguments to stnadard functions and out-of-bound array or std::vector accesses seem among the more popular.

    Philipp

     
  • Borut Ražem

    Borut Ražem - 2012-03-17

    If fails in SDCCralloc.hpp, function create_cfg(), line 431:
    cfg[key_to_index[ic->key]].alive.insert(sym_to_index[std::pair<int, int>(i, k)]);

    The complete stack trace is here:

    sdcc.exe!std::_Tree<std::_Tset_traits<short,std::less<short>,std::allocator<short>,0> >::_Linsert(std::_Tree_nod<std::_Tset_traits<short,std::less<short>,std::allocator<short>,0> >::_Node * _Node, bool _Leftish) Line 947 + 0x8 bytes C++
    sdcc.exe!std::_Tree<std::_Tset_traits<short,std::less<short>,std::allocator<short>,0> >::insert<short &>(short & _Val) Line 756 + 0x24 bytes C++
    sdcc.exe!create_cfg(boost::adjacency_list<boost::vecS,boost::vecS,boost::bidirectionalS,cfg_node,boost::no_property,boost::no_property,boost::listS> & cfg, boost::adjacency_list<boost::setS,boost::vecS,boost::undirectedS,con_node,boost::no_property,boost::no_property,boost::listS> & con, ebbIndex * ebbi) Line 341 + 0x60 bytes C++
    sdcc.exe!z80_ralloc2_cc(ebbIndex * ebbi) Line 1414 + 0x11 bytes C++
    sdcc.exe!z80_ralloc(ebbIndex * ebbi) Line 3151 + 0x9 bytes C
    sdcc.exe!z80_assignRegisters(ebbIndex * ebbi) Line 3211 + 0x9 bytes C
    sdcc.exe!eBBlockFromiCode(iCode * ic) Line 2132 + 0x14 bytes C
    sdcc.exe!emitRegularMap(memmap * map, unsigned char addPublics, unsigned char arFlag) Line 298 + 0x12 bytes C
    sdcc.exe!emitMaps() Line 1551 + 0xf bytes C
    sdcc.exe!glue() Line 1798 C
    sdcc.exe!main(int argc, char * * argv, char * * envp) Line 2574 + 0xc bytes C

    The exceptrion is:

    First-chance exception at 0x006e91b3 in sdcc.exe: 0xC0000005: Access violation reading location 0xcdcdcdd1.

    which means reading from a wrong location. It seems like dereferencing an unititialized pointer to me.

    P.S.: I'm not sure if this is related to the original Woody's problem...

    Borut

     
  • Erik Petrich

    Erik Petrich - 2012-03-17

    Borut,

    It appears you've successfully reproduced the bug reported in 3475617, although you have more debugging information displaying (they only had raw addresses instead of line number and offset). At least we have a line number now; the debugger's description of these templated methods makes my head spin!

    Erik

     
  • Philipp Klaus Krause

    I've added some assetions to track this down in revision #7529. Is there an error message when using current sdcc before the crash?

    Philipp

     
  • Borut Ražem

    Borut Ražem - 2012-04-03

    I tried it with the snapshot sdcc version:

    >..\bin\sdcc --version
    SDCC : mcs51/gbz80/z80/z180/r2k/ds390/pic16/pic14/TININative/ds400/hc08 3.1.4 #7525 (Apr 2 2012) (MINGW32)

    dtmf.c compiled without problems, but the build failed later on without any additional error messages while compiling sntp.c:

    n:\tmp\bug_3506333\sdcc\BIN\sdcc sntp.c -mz80 -c --std-c99 --max-allocs-per-node 6000 --codeseg CODE2
    Caught signal 11: SIGSEGV
    ..\bin\make: *** [sntp.rel] Error 1

    Borut

     
  • Philipp Klaus Krause

    Can you try once more? I added another two assertions (in #7531).

    Philipp

     
  • Woody

    Woody - 2012-04-05

    I downloaded #7530, found a lot of new warnings like:
    Warning: z80instructionSize() failed to parse line node di
    Warning: z80instructionSize() failed to parse line node ei
    Warning: z80instructionSize() failed to parse line node nop
    Warning: z80instructionSize() failed to parse line node push iy
    Warning: z80instructionSize() failed to parse line node push af
    Warning: z80instructionSize() failed to parse line node exx
    The source code related with those instructions are all inline asm:
    __asm
    // di
    exx
    push af
    push iy
    __endasm;

    Finally, caught signal 11 in sntp.c without any special warning or error:
    C:\SDCC\BIN\sdcc sntp.c -mz80 -c --std-c99 --codeseg CODE2
    Caught signal 11: SIGSEGV

     
  • Woody

    Woody - 2012-04-05

    I tried --oldralloc option just now,, z80instructionSize() failed warning and caught signal 11 in sntp.c appeared the same.

     
  • Philipp Klaus Krause

    Could you file a separate bug report for the z80instructionSize() issue? Please attach source code to rreporduce that one there, too. I suspect it is an issue with the inline asm containing a different type of whitespace from what z80instructionSize() expects.

    Philipp

     
  • Woody

    Woody - 2012-04-06

    Build #7531 is the same as #7530, no special error before:
    C:\SDCC\BIN\sdcc sntp.c -mz80 -c --std-c99 --codeseg CODE2
    Caught signal 11: SIGSEGV
    ..\bin\make: *** [sntp.rel] Error 1

     
  • Philipp Klaus Krause

    This lis most likely the same issue as #3506333, though this one occours on Windows and the other one on Solaris.

    Philipp

     
  • Borut Ražem

    Borut Ražem - 2012-04-08

    I noticed that ds390 library file ds390/_atof.rel compilation dies with SIGSEGV if sdcc is compiled with -O0 instead of the default -O2 optimization option:

    make[4]: Entering directory `/home/borutr/svn_snapshots/sdcc/sdcc.build/device/lib'
    ../../bin/sdcc -I../../../sdcc/device/include -I../../../sdcc/device/include/mcs51 -mds390 --nostdinc --std-c99 -c ../../../sdcc/device/lib/_atof.c -o ds390/_atof.rel
    Caught signal 11: SIGSEGV
    make[4]: *** [ds390/_atof.rel] Error 1

    Sdcc version:
    SDCC : mcs51/gbz80/z80/z180/r2k/ds390/pic16/pic14/TININative/ds400/hc08 3.1.4 #7552 (Apr 8 2012) (Linux)
    on x86_64 Linux

    Borut

     
  • Woody

    Woody - 2012-08-10

    Tested again just now, no problem with current build #8062.

     
  • Philipp Klaus Krause

    • assigned_to: nobody --> spth
    • status: open --> closed-fixed
     
  • Philipp Klaus Krause

    So it seems this bug went away sometime near the 3.2.0 release.

    Philipp

     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks