Re: [Tecomp-user] tecomp 0.7 on Mac OS X

[Helmut B. <hel...@gm...>]

Hello Martin,

thanks for trying. Unfortunately this does not yet give a lot of 
information. I have just seen that I did not activate debug information 
in the compiler flags.

In order to find out more I suggest the following:

1. Activate debug information:

- edit cal/build/flags.mk: CFLAGS_DEBUG = -ggdb -Wall ....

- rm gen_dir/obj/*n.o

- make -C test/class test

The last step will again fail, but now we have the sources compiled with 
debug information for gdb.

2. Find the line in the test code, where the failure occurs:

The test suite is rather simple and it is easy to step through it and 
encounter the location where the segfault happens. The first thing would 
be to enter into the method "execute" of test/class/test_class.cpp. The 
source code looks like:

void
test_class_t::
execute()
{
    test_namespace();
    test_names();
    test_topisort();

    init_basic_types();
    init_basic_types_old();
    init_abcde();
    init_generics();
    test_path();
    test_types();
    test_conformance();
    test_generic_substitution();
//     test_features();
    test_code();
}

I.e. set a breakpoint at the entry and step through it by next. Then we 
can see which one of the teststeps fails. On my system the following 
commands take me to the start of execute:

gdb gen_dir/bin/rtest_class
start
step
step
step
step

Now I can see with list the source code of "execute"

 From now on each "next" executes one teststep.


The next step would be to step through the failing teststep and find the 
point of failure there (the teststeps are basically linear chunks of 
code without ifs and loops).

It would help me to analyze the error if you can give the the line, 
where the failure occurs and a backtrace after the segfault.

Sorry for the inconveneance.

Regards
Helmut




sa...@gm... wrote:
> Here is what I get running rtest_class with gdb:
>
> Starting program: /Volumes/Scratch/tecomp/gen_dir/bin/rtest_class
> Reading symbols for shared libraries +++. done
>
> Program received signal EXC_BAD_ACCESS, Could not access memory.
> Reason: KERN_INVALID_ADDRESS at address: 0xfffffff4
> 0x92d7386c in std::string::assign ()
> (gdb) bt
> #0  0x92d7386c in std::string::assign ()
> #1  0x00035cc0 in feature_name_t::feature_name_t ()
> #2  0x00067e64 in class_collection_t::class_collection_t ()
> #3  0x000f1f84 in __static_initialization_and_destruction_0 ()
> #4  0x000f2c44 in global constructors keyed to  
> _ZNK12test_class_t4nameEv ()
> #5  0x8fe1376c in  
> __dyld__ZN16ImageLoaderMachO18doModInitFunctionsERKN11ImageLoader11LinkContextE 
>   ()
> #6  0x8fe0f180 in  
> __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEj ()
> #7  0x8fe0f2a4 in  
> __dyld__ZN11ImageLoader15runInitializersERKNS_11LinkContextE ()
> #8  0x8fe03848 in __dyld__ZN4dyld24initializeMainExecutableEv ()
> #9  0x8fe0807c in __dyld__ZN4dyld5_mainEPK11mach_headermiPPKcS5_S5_ ()
> #10 0x8fe01774 in  
> __dyld__ZN13dyldbootstrap5startEPK11mach_headeriPPKcl ()
> #11 0x8fe01048 in __dyld__dyld_start ()
> (gdb)
>
> Regards,
> Martin
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> Tecomp-user mailing list
> Tec...@li...
> https://lists.sourceforge.net/lists/listinfo/tecomp-user
>
>