From: SourceForge.net <no...@so...> - 2012-03-17 17:03:11
|
Bugs item #3506333, was opened at 2012-03-16 12:45 Message generated for change (Comment added) made by epetrich You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3506333&group_id=599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: z80 port Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Woody (woody1234) Assigned to: Nobody/Anonymous (nobody) Summary: Caught sigal 11: SIGSEGV Initial Comment: 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. ---------------------------------------------------------------------- >Comment By: Erik Petrich (epetrich) Date: 2012-03-17 10:03 Message: 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 ---------------------------------------------------------------------- Comment By: Borut Ražem (borutr) Date: 2012-03-17 02:56 Message: 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 ---------------------------------------------------------------------- Comment By: Philipp Klaus Krause (spth) Date: 2012-03-17 01:21 Message: 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 ---------------------------------------------------------------------- Comment By: Borut Ražem (borutr) Date: 2012-03-16 23:02 Message: 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 ---------------------------------------------------------------------- Comment By: Borut Ražem (borutr) Date: 2012-03-16 22:49 Message: 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 ---------------------------------------------------------------------- Comment By: Woody (woody1234) Date: 2012-03-16 21:49 Message: 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. ---------------------------------------------------------------------- Comment By: Borut Ražem (borutr) Date: 2012-03-16 16:03 Message: 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 ---------------------------------------------------------------------- Comment By: Woody (woody1234) Date: 2012-03-16 12:58 Message: 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 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3506333&group_id=599 |