[sdcc-devel] [ sdcc-Bugs-3475617 ] Source build SEGV building z80/r2k/z180/gbz80 libs

[SourceForge.net <no...@so...>]

Bugs item #3475617, was opened at 2012-01-18 12:29
Message generated for change (Comment added) made by borutr
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3475617&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: Brian Ruthven (u6c87)
Assigned to: Nobody/Anonymous (nobody)
Summary: Source build SEGV building z80/r2k/z180/gbz80 libs

Initial Comment:
Building sdcc-20120118-7234 from source, the compile of _atof.c fails with a SEGV, but only for the z80, z180, r2k and gbz80 ports (although I'm not sure about the pic ports as I don't have all the bits to build them). The relevant failure of the build for z80 is this:


if [ -f z80/Makefile ]; then \
          gmake -C z80 PORT=z80; \
        fi
gmake[5]: Entering directory `/build/sdcc-20120118-7234/device/lib/z80'
../../../bin/sdcc -mz80 -I./../../include -I. --std-c99 -c ../_atof.c
Caught signal 11: SIGSEGV
gmake[5]: *** [_atof.rel] Error 1
gmake[5]: Leaving directory `/build/sdcc-20120118-7234/device/lib/z80'
gmake[4]: [port-specific-objects] Error 2 (ignored)

$ truss -lf -S SEGV -t!all -sSEGV gmake
[ many lines elided ]
gmake[5]: Entering directory `/build/sdcc-20120118-7234/device/lib/z80'
../../../bin/sdcc -mz80 -I./../../include -I. --std-c99 -c ../_atof.c
20350/1:	    Incurred fault #6, FLTBOUNDS  %pc = 0xFEF2E6ED
20350/1:	      siginfo: SIGSEGV SEGV_MAPERR addr=0x00000004
20350/1:	    Received signal #11, SIGSEGV [caught]
20350/1:	      siginfo: SIGSEGV SEGV_MAPERR addr=0x00000004

$ pstack 20350 | c++filt
20350:	../../../bin/sdcc -mz80 -I./../../include -I. --std-c99 -c ../_atof.c
 fef2e6ed std::_Rb_tree_decrement(std, _Rb_tree_node_base) (803d598, 803d5a0, 803d5a8, 81fb81d, 855e9a8, 0) + d
 081f8a5d std::_Rb_tree<short, short, std, _Identity<short>, std, less<short>, std::allocator,<short>void>::_M_insert_unique(const short&) (803d5e4, 855e9c4, 8422788, 803d728, 803d7bc, 803d70c) + 12b
 081f7403 std::set<short, std, less<short>, std::allocator,<short>void>::insert(const short&) (803d7cc, 855e9c4, 8422788, 803d8f0, 8446228, 0) + 23
 0826a870 _Z10create_cfgRN5boost14adjacency_listINS_4vecSES1_NS_14bidirectionalSE8cfg_nodeNS_11no_propertyES4_NS_5listSEEERNS0_INS_4setSES1_NS_11undirectedSE8con_nodeS4_S4_S5_EEP8ebbIndex (803d8f0, 803d8d8, 85225a0, 0, 85305d8, 803d8fc) + 819
 082683b4 z80_ralloc2_cc (85225a0, 16, 8324eed, 1, 8324d4c, b56) + 44
 082671b3 z80_ralloc (85225a0, 20, 1, 1, 82ee110, 4b5) + 283
 08194813 eBBlockFromiCode (8441450, 82f03ea, 82f03e3, 2, 82ee5a4, 19c5) + be3
 081aa94a createFunction (84234c8, 8439480, 8423458, 8433528, 8436420, 55e) + 6ea
 0817919b yyparse  (83ca768, 0, 82ead6f, 1, 2, 8269860) + 40cb
 0817eae8 main     (7, 8047780, 80477a0, 8173c32, 82e5a20, 0) + 10a8
 08173c93 _start   (7, 80478ec, 80478fe, 8047904, 8047916, 804791a) + 83


This seems to be related to a recently fixed bug - 3466784 which was reported against the mcs51 build.

I'm using GCC 4.5.2 to build sdcc on Solaris 11 with Boost 1.47.0.
$ bin/sdcc -v
SDCC : mcs51/gbz80/z80/z180/r2k/ds390/TININative/ds400/hc08 3.1.2 #7234 (Jan 18 2012) (Solaris i386)


I can provide gcore dumps or full build logs, etc.. if required. Let me know what you want.

----------------------------------------------------------------------

>Comment By: Borut Ražem (borutr)
Date: 2012-03-20 14:58

Message:
I reproduced the problem on Windows XP with Visual Studio 2010 in debug
mode:
If dies with "First-chance exception at 0x006e91b3 in sdcc.exe: 0xC0000005:
Access violation reading location 0xcdcdcdd1." in file SDCCralloc.hpp,
function create_cfg(), line 431:

cfg[key_to_index[ic->key]].alive.insert(sym_to_index[std::pair<int, int>(i,
k)]);

After some investigation I found out that cfg[key_to_index[ic->key]].alive
and cfg[key_to_index[ic->key]].dying members are not initialized:

-		cfg[key_to_index[ic->key]]	{ic=0x02d1b0b0 operands=[0x00000000]()
alive=[0xcccccccc](...) ...}	cfg_node
+		ic	0x02d1b0b0 {op=0x0000003d key=0x000000a4 seq=0x00000003 ...}	iCode *
+		operands	[0x00000000]()	std::multimap<int,short,std::less<int>,std::allocator<std::pair<int
const ,short> > >
+		alive	[0xcccccccc](...)	std::set<short,std::less<short>,std::allocator<short>
>
+		dying	[0xcccccccc](...)	std::set<short,std::less<short>,std::allocator<short>
>

I found the initialization of ic member at line 283:

cfg[i].ic = ic;

but I didn't find the alive and dying members initialization.

Borut


----------------------------------------------------------------------

Comment By: Brian Ruthven (u6c87)
Date: 2012-01-18 13:58

Message:
I can reproduce this with sdcc-20120113-7211 but not sdcc-20120112-7209.
Configure line in both cases was:

$ ./configure --prefix=/tmp/sdcc --disable-mcs51-port --disable-gbz80-port
--disable-ds390-port --disable-ds400-port --disable-pic16-port
--disable-pic14-port --disable-hc08-port --disable-ucsim --disable-sdcdb
--disable-r2k-port --disable-gbz80-port

(with CXXFLAGS set to -I/build/boost_1_47_0 which is where boost is
unpacked for this test).

I've attached the configure output, config.log and gmake output for
reference.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3475617&group_id=599