Re: [Swig-devel] Debugging Swig 3.0 and C++11

[William S F. <ws...@fu...>]

SWIG should not seg fault, so I've just committed a fix. Please try it 
out. The stack trace when seg faulting for the cut down example you gave 
is different to the one you originally provided. It could possibly be 
the same reason, so please report back if your large code now works.

William

On 03/12/13 11:57, Pierre-Henri Wuillemin wrote:
> Hi again,
>
> Thank you William for your answers.
>
> With your advise, I think I found the problem. It is documented and a warning
> even appears (warning 342), but still I guess it is good to know that using
> "using" for partial elicitation of template parameters provokes a segmentation
> fault (core duped)
>
> I have this kind of minimal test class :
>
> ------------------------------------------------------------------
> template<typename Key,typename Val>
> class MyCPP11Class {
>    ...
> }
>
> template<typename VAL> using MyIntKeyClass = MyCPP11Class<int,VAL>;
>
> MyIntKeyClass<char> c;
> --------------------------------------------------------------------
>
> trying to parse this kind of header file in a "%include" ends up with
> segmentation fault.
>
> Best regards !
>
>
>
> swi...@li...
>
> Le lundi 25 novembre 2013 19:31:09 vous avez écrit :
>> On 25/11/13 17:06, Pierre-Henri Wuillemin wrote:
>>> Hi,
>>>
>>> Thanks to the last updates in swig 3.0 (Fix some cases of C++11 exception
>>> specifications on constructors with =default or =delete), I have been able
>>> to try it on a quite large library that is moving to C++11 (I still had
>>> to remove "final" and "override" keywords from the C++11 sources).
>>>
>>> It appears that swig terminates with a segmentation fault (core dumped)
>>> when parsing my .i file.
>>>
>>> 	- swig 2.0 worked correctly with the C++ version of the library.
>>> 	
>>>    	- the C++11 version of the library compiles and passes its test
>>>    	correctly
>>>
>>> (and the .i file did not change).
>>>
>>>    It is a large and (at least for me) complex and intricate .i file so it
>>>    is
>>>
>>> difficult to create a minimal version that creates the bugs.
>>>
>>> I can at least give the backtrace produced by gdb (ubuntu 13.10, g++
>>> 4.8.1,
>>> SWIG Version 3.0.0, Compiled with g++
>>> [x86_64-unknown-linux-gnu],Configured
>>> options: +pcre).
>>>
>>>
>>> Program received signal SIGSEGV, Segmentation fault.
>>> __strstr_sse42 (s1=0x0, s2=0x507256 "operator ") at
>>> ../sysdeps/x86_64/multiarch/strstr.c:174
>>> 174     ../sysdeps/x86_64/multiarch/strstr.c: Aucun fichier ou dossier de
>>> ce type.
>>> (gdb) bt
>>> #0  __strstr_sse42 (s1=0x0, s2=0x507256 "operator ") at
>>> ../sysdeps/x86_64/multiarch/strstr.c:174
>>> #1  0x00000000004ee0c6 in Swig_scopename_check (s=s@entry=0x0) at
>>> Swig/misc.c:1044
>>> #2  0x00000000004f922b in Swig_symbol_clookup_local (name=0x0,
>>> n=n@entry=0x128b320) at Swig/symbol.c:1252
>>> #3  0x00000000004f9295 in Swig_symbol_clookup_local
>>> (name=name@entry=0x214f460, n=<optimized out>, n@entry=0x128b320) at
>>> Swig/symbol.c:1273
>>> #4  0x00000000004f8932 in Swig_symbol_template_deftype
>>> (type=type@entry=0x214f320, tscope=tscope@entry=0x128b320) at
>>> Swig/symbol.c:1957
>>> #5  0x00000000004f8cf5 in _symbol_lookup (name=0x214f320,
>>> symtab=0x128b320,
>>> check=0x0) at Swig/symbol.c:962
>>> #6  0x00000000004f94ba in Swig_symbol_clookup (name=name@entry=0x214f320,
>>> n=n@entry=0x0) at Swig/symbol.c:1134
>>> #7  0x00000000004f9f7e in Swig_symbol_cadd (name=name@entry=0x214f220,
>>> n=n@entry=0x214f1c0) at Swig/symbol.c:639
>>> #8  0x00000000004fa30b in Swig_symbol_add (symname=symname@entry=0x0,
>>> n=n@entry=0x214f1c0) at Swig/symbol.c:727
>>> #9  0x0000000000409b98 in add_symbols (n=n@entry=0x214f1c0) at
>>> CParse/parser.y:469
>>> #10 0x00000000004146e7 in yyparse () at CParse/parser.y:3160
>>> #11 0x000000000041a24b in Swig_cparse (f=<optimized out>) at
>>> CParse/parser.y:1411
>>> #12 0x0000000000484c9b in SWIG_main (argc=<optimized out>, argv=<optimized
>>> out>, l=<optimized out>) at Modules/main.cxx:1154
>>> #13 0x0000000000406515 in main (margc=<optimized out>, margv=<optimized
>>> out>) at Modules/swigmain.cxx:206
>>>
>>>
>>> Tell me if you need or how I can give you more informations.
>>>
>>> Best regards and thanks for swig !
>>
>> If you can't cut it down to a simple example, can you 'install' the swig
>> gdb debugging support. It is very easy as described in
>> Doc/Devel/internals.html#i7, that is, the "7. Debugging SWIG" section.
>> In gdb, go up to the add_symbols function when it seg faults and run:
>>
>> locswigprint n
>>
>> Which will print out the parse node as well as the relevant source file
>> and line number. Please send this info. Even better, the file/line info
>> should give you a jolly good idea as to how to replicate the problem as
>> it points to the source line that causes the issue. Also, you might see
>> a warning with this info from line 466 in parser.y just before it bombs
>> out on line 469:
>>
>> 465	SWIG_WARN_NODE_BEGIN(n);
>> 466	Swig_warning(0,Getfile(n), Getline(n), "%s\n",c+1);
>> 467	SWIG_WARN_NODE_END(n);
>> 468      }
>> 469      Swig_symbol_add(0, n);
>>
>> Re the final and override keywords in C++11, I'll add these in, but
>> first, I need to merge in the nested class support, which is pretty much
>> what I am going to do next.
>>
>> William
>