segmentation fault in PyInit_libgraph_tool_generation () at graph_generation.cc:99

graph-tool
1

Hi, using the latest git (or the release version), I get a segfault:

$/usr/bin/python3.3 -c 'import graph_tool.all as gt' ; tail -n 1 /var/log/messages
Segmentation fault
Jan 19 04:42:12 localhost kernel: [196711.282646] python3.3[18903]: segfault at 16ae16 ip 000000000016ae16 sp 00007ffff2286a18 error 14 in libgmp.so.10.1.3[7f05c5edb000+78000]

The end of the backtrace says:

Program received signal SIGSEGV, Segmentation fault.
0x00000000011ab766 in ?? ()
#0 0x00000000011ab766 in ?? ()
#1 0x00007fffc3ddc357 in PyInit_libgraph_tool_generation () at graph_generation.cc:99
#2 0x00007ffff7a50afc in _PyImport_LoadDynamicModule (name='graph_tool.generation.libgraph_tool_generation', path='/usr/lib64/python3.3/site-packages/graph_tool/generation/libgraph_tool_generation.so', fp=0x0) at /var/tmp/portage/dev-lang/python-3.3.5-r1/work/Python-3.3.5/Python/importdl.c:86
#3 0x00007ffff7a50564 in imp_load_dynamic (self=<module at remote 0x7ffff7f40b90>, args=('graph_tool.generation.libgraph_tool_generation', '/usr/lib64/python3.3/site-packages/graph_tool/generation/libgraph_tool_generation.so')) at
/var/tmp/portage/dev-lang/python-3.3.5-r1/work/Python-3.3.5/Python/import.c:1801
#4 0x00007ffff7976f07 in PyCFunction_Call (func=<built-in method load_dynamic of module object at remote 0x7ffff7f40b90>, arg=('graph_tool.generation.libgraph_tool_generation', '/usr/lib64/python3.3/site-packages/graph_tool/generation/libgraph_tool_generation.so'), kw={})
    at /var/tmp/portage/dev-lang/python-3.3.5-r1/work/Python-3.3.5/Objects/methodobject.c:81

Full backtraces and system information @ https://bugs.gentoo.org/show_bug.cgi?id=537042

line 99 of: https://github.com/count0/graph-tool/blob/master/src/graph/generation/graph_generation.cc seems to be the fault location

Any idea on what I should try to further isloate this?

using:
gcc 4.8.3
boost-1.56.0-r1
gmp-5.1.3-r1

Thanks! -Justin

2

This looks most likely like a mismatch between python and
boost-python. Verify that you are using the same version of python when
compiling boost-python and graph-tool.

Best,
Tiago

3

This looks most likely like a mismatch between python and
boost-python. Verify that you are using the same version of python when
compiling boost-python and graph-tool.

Thanks Tiago, I recompiled boost, libgmp, and graph-tool with py3.3 support only. Same issue.

$/usr/bin/python2.7 -c 'import graph_tool.all as gt'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ImportError: No module named graph_tool.all

root(a)xeonbox /usr/lib64 $/usr/bin/python3.3 -c 'import graph_tool.all as gt'
Segmentation fault

root(a)xeonbox /usr/lib64 $tail -n 1 /var/log/messages
Jan 27 14:48:27 localhost kernel: [223943.748612] python3.3[19331]: segfault at 1b1b56 ip 00000000001b1b56 sp 00007fffe5a7d588 error 14 in libgmp.so.10.2.0[7f98d6d4c000+79000]

LD_DEBUG="all" shows one unresolved symbol shortly before the segfault:

18820: /usr/lib64/python3.3/site-packages/graph_tool/generation/libgraph_tool_generation.so: error: symbol lookup error: undefined symbol: _ZNKSt3tr14hashISt6vectorISsSaISsEEEclES3_ (fatal)

$nm -D /usr/lib64/python3.3/site-packages/graph_tool/generation/libgraph_tool_generation.so | grep _ZNKSt3tr14hashISt6vectorISsSaISsEEEclES3_
                 U _ZNKSt3tr14hashISt6vectorISsSaISsEEEclES3_

demangler.com converts that to:
std::tr1::hash<std::vector<std::string, std::allocator<std::string> > >::operator()(std::vector<std::string, std::allocator<std::string> >) const

Is this from line 564 in src/graph/graph_util.hh?

gdb shows that var that $pc eventually gets set by being set to 0x00000000001b1b56 before I break @ graph_generation.cc:99

https://537042.bugs.gentoo.org/attachment.cgi?id=395036

I also switched to gcc 4.9.2 and recompiled everything relevant. Same result.

Per a suggestion in #gentoo I removed the tr1/ before the 3 includes in /src/graph_tool/run_action/run_action_support.hh and recompiled. Same result.

Full bug report with logs: 537042 – dev-python/graph-tool - segmentation fault in PyInit_libgraph_tool_generation () at graph_generation.cc:99

Further suggestions are most appreciated!

-Justin

4

Do you have sparsehash enabled?

5

Quoting Tiago de Paula Peixoto (2015-01-28 02:11:19)

Do you have sparsehash enabled?

sparsehash 2.0.2 is installed at:

/usr/include/sparsehash

and the graph-tool configure log indicates it found it:

checking whether to enable sparsehash...... yes
checking sparsehash/dense_hash_set usability... yes
checking sparsehash/dense_hash_set presence... yes
checking for sparsehash/dense_hash_set... yes

the graph-tool build log shows it was compiled with:

-DSPARSEHASH_PREFIX=sparsehash

I noticed scipy was not compiled with sparsehash support, I recompiled it with, and then numpy, boost and graph-tool.

Unfortunately, same result:

$/usr/bin/python3.3 -c 'import graph_tool.all as gt'
Segmentation fault
$tail -n 1 /var/log/messages
Jan 28 02:23:34 localhost kernel: [265651.426137] python3.3[20053]: segfault at 1b1b56 ip 00000000001b1b56 sp 00007fffe397e5a8 error 14 in libgmp.so.10.2.0[7f6a80db0000+79000]

-Justin

6

Can you try disabling sparsehash, with --disable-sparsehash, and see if
the problem persists? This should get rid of any tr1 references.

(This is very strange, BTW, since I cannot reproduce it.)

Best,
Tiago

7

Quoting Tiago de Paula Peixoto (2015-01-28 04:47:21)

Can you try disabling sparsehash, with --disable-sparsehash, and see if
the problem persists? This should get rid of any tr1 references.

That did it!
         
$/usr/bin/python3.3 -c 'import graph_tool.all as gt ; print(gt.__version__)'
2.2.37dev (commit 201879ac, Fri Jan 9 15:46:17 2015 +0100)
            
I am more than happy to continue debugging this until we figure out why enabling sparsehash results in a segfault, let me know what I can do.
           
Thanks!
-Justin

8

Can you try the patch attached, and re-enable sparsehash?

Best,
Tiago

removetr1hash.patch (2.59 KB)

9

Quoting Tiago de Paula Peixoto (2015-01-28 13:41:53)

Can you try the patch attached, and re-enable sparsehash?

Yes, I applied the patch "patching file src/graph/generation/graph_rewiring.hh" and then removed the --disable-sparsehash switch from ./configure, and the configure log shows:

checking whether to enable sparsehash...... yes
checking for SPARSEHASH... yes
checking sparsehash/dense_hash_set usability... yes
checking sparsehash/dense_hash_set presence... yes
checking for sparsehash/dense_hash_set... yes

recompiled graph-tool only, and the problem returned:

$/usr/bin/python3.3 -c 'import graph_tool.all as gt ; print(gt.__version__)'
Segmentation fault
$tail -n1 /var/log/messages
Jan 28 16:58:57 localhost kernel: [18269.366654] python3.3[22192]: segfault at 1710c6 ip 00000000001710c6 sp 00007fffdf06d548 error 14 in libgmp.so.10.2.0[7f201b80c000+79000]

-Justin

10

Is the GDB backtrace the same as before? Is the missing symbol also the
same?

Best,
Tiago

11

Quoting Tiago de Paula Peixoto (2015-01-29 01:14:36)

Is the GDB backtrace the same as before? Is the missing symbol also the same?

Yes, with the patch applied, and sparsehash enabled, the backtrace is the same (minor change in the segfault address), and the missing symbol is still _ZNKSt3tr14hashISt6vectorISsSaISsEEEclES3_

Full test log:

https://537042.bugs.gentoo.org/attachment.cgi?id=395102

-J

12

The patch attached should finally take care of it. Could you please test it?

Best,
Tiago

remove_all_tr1hash.patch (10.6 KB)

13

Quoting Tiago de Paula Peixoto (2015-01-29 07:35:52)

The patch attached should finally take care of it. Could you please test it?

Yes, confirmed, the patch fixes the segfault with sparsehash enabled.

Thank you!

-Justin

14

The modifications are now in the git version.

Best,
Tiago

15

Quoting Tiago de Paula Peixoto (2015-01-29 15:54:14)

The modifications are now in the git version.

Great, thanks.

Did you fix a bug with "git clone" on the skewed.de server?

"git clone https://git.skewed.de/count0/graph-tool.git&quot;

previously, it would almost always time-out, therefore we are currently using the github repo in portage.

-Justin

16

This has been fixed now. You can go back using the official repository.

Best,
Tiago