Mac OS X is supported by tecomp. But the problem might be due to the processor. What processor do you have? Is it an Intel or a PowerPC.
If it is a PowerPC (Motorola), the problem is probably due to an alignment bug in tecomp which I have fixed a couple of days ago for a user with Sun/Sparc (see tecomp mailing list).
Could you please compile the fully debug version of tecomp with
make atecomp
and run atecomp (it is placed in gen_dir/bin beside the optimized tecomp) in gdb and send me the stack trace?
Thanks
Helmut
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2009-12-03
I have an Intel Mac. I am not in the right partition right now, but I will try it later as you suggested.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I get a Segmentation Fault running tecomp on Mac OS X 10.6.8 Intel processor.
Clive-Haywards-MacBook-Air:tecomp-0.24.1 haywardc$ src/tecomp/atecomp
Segmentation fault
Clive-Haywards-MacBook-Air:tecomp-0.24.1 haywardc$ gdb !!
gdb src/tecomp/atecomp
GNU gdb 6.3.50-20050815 (Apple version gdb-1515) (Sat Jan 15 08:33:48 UTC 2011)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin"…Reading symbols for shared libraries … done
(gdb) run
Starting program: /Users/haywardc/Downloads/tecomp-0.24.1/src/tecomp/atecomp
Reading symbols for shared libraries ++. done
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000008
0x00007fff807f6fa1 in std::_Rb_tree_decrement ()
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
thanks for the detailed report. The problem seems to happen at the point where one key value pair is entered into an stl::map. Up to know this problem has not appeared with all other stl implementations I have encountered. The trace indicates that the problem appears at the start up phase of tecomp where a lot of default feature names are entered into an stl::map.
Can you find out with gdb what causes the access to address 0x0000000000000008 which definitely should not happen?
It is not yet clear to me what happens there. Could you try to edit src/class/map_to_iter.h and replace line 54
void extend(const K& key){
by
void extend(const K key){
i.e. remove the "&" and try it again.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2012-07-17
I have managed to figure out a fix for this bug. The static map held by the feature_name_t class doesn't get properly initialized. The fix is to call clear() on the map before the first insert - this places the object in a sane state.
In the latest build 0.24.1 in the file "/src/class/feature_name.cpp" at line 102 insert "names.wipeout();"
Output for the test.ace
clive-haywards-macbook-pro-2:tecomp chayward$ ./atecomp test.ace
n8 = 128 m8 = 128
100 0.333333 False True z
My baby baby balla balla …
(10).hash_code = 2922037562
(100).hash_code = 1303088196
(-1).hash_code = 3788015175
("abcd").hash_code = 2170705594
("xyz").hash_code = 1487575379
char array:
char array:
Hello world
blabla0123
^$
#|{}
ab
2100000000
Hello, world.
Each
word
on
a
new
line
1.5
2.5
4
0. = 0 -0. = -0
1. = 1
(1101.01).out = 1101.01
e= e.twin=
i = 2000000000
i+i = 4000000000
i*i = 4000000000000000000
i = 2000000000
i+i = 4000000000
i*i = 4000000000000000000
Clive Hayward
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
For me it is not yet clear what the root cause of the error is. Why does the map in "names" not get properly initialized and why does the map in "ops" get properly initialized. From my understanding of C++ static objects must be initialized before "main" starts.
Actually the class "map_to_index_t" contains two containers. One of type "std::map" and one of type "sequence_arrayed__t".
Could you do me the favor to remove temporarily your fix and add a constructor into the class "map_to_index_t" at line 26 of file src/class/map_to_index.h"
map_to_index_t() {m.clear();seq.wipe_out();}
and see if this fixes the error as well? And if this fix works try the constructor with either "m.clear()" or "seq.wipe_out()" to see which of the two objects does not get initialized.
Sorry for asking this favor, but since I have no Mac computer available a cannot try it myself. And the problem seems to appear only on Mac OS (or on this specific version of gcc).
Anyhow. If the fix works with the constructor in map_to_index_t, I would add it to the next release.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
I just compiled it on Mac OS X, and got a "bus error" when running the compiler.
Is Mac OS X supported? If not, any chance it can happen :)
Thanks,
Quenio
Hello Quenio,
Mac OS X is supported by tecomp. But the problem might be due to the processor. What processor do you have? Is it an Intel or a PowerPC.
If it is a PowerPC (Motorola), the problem is probably due to an alignment bug in tecomp which I have fixed a couple of days ago for a user with Sun/Sparc (see tecomp mailing list).
Could you please compile the fully debug version of tecomp with
make atecomp
and run atecomp (it is placed in gen_dir/bin beside the optimized tecomp) in gdb and send me the stack trace?
Thanks
Helmut
I have an Intel Mac. I am not in the right partition right now, but I will try it later as you suggested.
I get a Segmentation Fault running tecomp on Mac OS X 10.6.8 Intel processor.
Clive-Haywards-MacBook-Air:tecomp-0.24.1 haywardc$ src/tecomp/atecomp
Segmentation fault
Clive-Haywards-MacBook-Air:tecomp-0.24.1 haywardc$ gdb !!
gdb src/tecomp/atecomp
GNU gdb 6.3.50-20050815 (Apple version gdb-1515) (Sat Jan 15 08:33:48 UTC 2011)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin"…Reading symbols for shared libraries … done
(gdb) run
Starting program: /Users/haywardc/Downloads/tecomp-0.24.1/src/tecomp/atecomp
Reading symbols for shared libraries ++. done
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000008
0x00007fff807f6fa1 in std::_Rb_tree_decrement ()
Full stack trace:
(gdb) bt
#0 0x00007fff807f6fa1 in std::_Rb_tree_decrement ()
#1 0x0000000100011f94 in std::_Rb_tree_iterator<std::pair<char_string_t const, unsigned int> >::operator- (this=0x7fff5fbfd0e0) at stl_tree.h:200
#2 0x0000000100012301 in std::_Rb_tree<char_string_t const, std::pair<char_string_t const, unsigned int>, std::_Select1st<std::pair<char_string_t const, unsigned int> >, std::less<char_string_t const>, std::allocator<std::pair<char_string_t const, unsigned int> > >::_M_insert_unique (this=0x1001f9400, __v=@0x7fff5fbfd210) at stl_tree.h:990
#3 0x00000001000124a5 in std::_Rb_tree<char_string_t const, std::pair<char_string_t const, unsigned int>, std::_Select1st<std::pair<char_string_t const, unsigned int> >, std::less<char_string_t const>, std::allocator<std::pair<char_string_t const, unsigned int> > >::_M_insert_unique (this=0x1001f9400, __position={_M_node = 0x1001f9408}, __v=@0x7fff5fbfd210) at stl_tree.h:1010
#4 0x00000001000127a7 in std::map<char_string_t const, unsigned int, std::less<char_string_t const>, std::allocator<std::pair<char_string_t const, unsigned int> > >::insert (this=0x1001f9400, __position={_M_node = 0x1001f9408}, __x=@0x7fff5fbfd210) at stl_map.h:427
#5 0x000000010001284e in std::map<char_string_t const, unsigned int, std::less<char_string_t const>, std::allocator<std::pair<char_string_t const, unsigned int> > >::operator (this=0x1001f9400, __k=@0x7fff5fbfd430) at stl_map.h:350
#6 0x0000000100012939 in map_to_index_t<char_string_t>::extend (this=0x1001f9400, key=@0x7fff5fbfd430) at map_to_index.h:57
#7 0x000000010000f100 in feature_name_t::init_features () at feature_name.cpp:102
#8 0x000000010001a655 in feature_name_t::check_features () at feature_name.h:102
#9 0x00000001000102fe in feature_name_t::find_or_insert (c=70 'F') at feature_name.cpp:30
#10 0x0000000100010545 in feature_name_t::feature_name_t (this=0x1001f8be0, cstr=0x10014f278 "make", c=70 'F') at feature_name.cpp:167
#11 0x0000000100008ccb in class_collection_t::class_collection_t (this=0x1001f8b20) at class_collection.cpp:217
#12 0x0000000100003912 in eiffel_system_t::eiffel_system_t (this=0x1001f8b20) at eiffel_system.h:42
#13 0x0000000100003ea9 in __static_initialization_and_destruction_0 (__initialize_p=1, __priority=65535) at tecomp.cpp:36
#14 0x0000000100003ed6 in global constructors keyed to _Z11print_usagev () at tecomp.cpp:236
#15 0x00007fff5fc0d500 in __dyld__ZN16ImageLoaderMachO18doModInitFunctionsERKN11ImageLoader11LinkContextE ()
#16 0x00007fff5fc0bcec in __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEj ()
#17 0x00007fff5fc0bda6 in __dyld__ZN11ImageLoader15runInitializersERKNS_11LinkContextE ()
#18 0x00007fff5fc0210e in __dyld__ZN4dyld24initializeMainExecutableEv ()
#19 0x00007fff5fc06981 in __dyld__ZN4dyld5_mainEPK12macho_headermiPPKcS5_S5_ ()
#20 0x00007fff5fc016d2 in __dyld__ZN13dyldbootstrap5startEPK12macho_headeriPPKcl ()
#21 0x00007fff5fc01052 in __dyld__dyld_start ()
Hello Quenio,
thanks for the detailed report. The problem seems to happen at the point where one key value pair is entered into an stl::map. Up to know this problem has not appeared with all other stl implementations I have encountered. The trace indicates that the problem appears at the start up phase of tecomp where a lot of default feature names are entered into an stl::map.
Can you find out with gdb what causes the access to address 0x0000000000000008 which definitely should not happen?
It is not yet clear to me what happens there. Could you try to edit src/class/map_to_iter.h and replace line 54
void extend(const K& key){
by
void extend(const K key){
i.e. remove the "&" and try it again.
I have managed to figure out a fix for this bug. The static map held by the feature_name_t class doesn't get properly initialized. The fix is to call clear() on the map before the first insert - this places the object in a sane state.
In the latest build 0.24.1 in the file "/src/class/feature_name.cpp" at line 102 insert "names.wipeout();"
Output for the test.ace
clive-haywards-macbook-pro-2:tecomp chayward$ ./atecomp test.ace
n8 = 128 m8 = 128
100 0.333333 False True z
My baby baby balla balla …
(10).hash_code = 2922037562
(100).hash_code = 1303088196
(-1).hash_code = 3788015175
("abcd").hash_code = 2170705594
("xyz").hash_code = 1487575379
char array:
char array:
Hello world
blabla0123
^$
#|{}
ab
2100000000
Hello, world.
Each
word
on
a
new
line
1.5
2.5
4
0. = 0 -0. = -0
1. = 1
(1101.01).out = 1101.01
e= e.twin=
i = 2000000000
i+i = 4000000000
i*i = 4000000000000000000
i = 2000000000
i+i = 4000000000
i*i = 4000000000000000000
Thank you Clive for finding this workaround.
For me it is not yet clear what the root cause of the error is. Why does the map in "names" not get properly initialized and why does the map in "ops" get properly initialized. From my understanding of C++ static objects must be initialized before "main" starts.
Actually the class "map_to_index_t" contains two containers. One of type "std::map" and one of type "sequence_arrayed__t".
Could you do me the favor to remove temporarily your fix and add a constructor into the class "map_to_index_t" at line 26 of file src/class/map_to_index.h"
map_to_index_t() {m.clear();seq.wipe_out();}
and see if this fixes the error as well? And if this fix works try the constructor with either "m.clear()" or "seq.wipe_out()" to see which of the two objects does not get initialized.
Sorry for asking this favor, but since I have no Mac computer available a cannot try it myself. And the problem seems to appear only on Mac OS (or on this specific version of gcc).
Anyhow. If the fix works with the constructor in map_to_index_t, I would add it to the next release.
Helmut,
Unfortunately, adding the constructor doesn't fix the problem. I believe the problem is related to the order of static object initialization. http://www.parashift.com/c++-faq-lite/static-init-order-on-first-use.html Here is another link describing the same phenomenon but under Linux http://www.instructables.com/answers/Why-would-an-empty-stdmap-seg-fault-on-the-first/ Note the comment from kelseymh "Well, the STL documentation says that the ctor creates an empty map. One piece of weirdness is that if I do explicity clear() the map in the class ctor, the insert works fine."
By the way only the map_to_index_t's 'm' map member is a problem, calling wipe_out() was the least intrusive way to get the clear() call performed.
Clive
Clive,
thanks for the detailed investigation. I will use your proposed workaround for the next release.
In the long run Iwill remove static objects which need initialisations (which is usually the case) completely because it is too fragile in C++.