From: William S F. <ws...@fu...> - 2013-11-25 19:31:23
|
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 |