segmentation fault in PyInit_libgraph_tool_generation () at graph_generation.cc:99
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_... 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
On 22.01.2015 23:15, "graph-tool"@v6y.net> wrote:
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_... seems to be the fault location
Any idea on what I should try to further isloate this?
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 -- Tiago de Paula Peixoto <tiago@skewed.de>
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@xeonbox /usr/lib64 $/usr/bin/python3.3 -c 'import graph_tool.all as gt' Segmentation fault root@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: https://bugs.gentoo.org/show_bug.cgi?id=537042 Further suggestions are most appreciated! -Justin
On 27.01.2015 23:02, graph-tool@v6y.net wrote:
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.
Do you have sparsehash enabled? -- Tiago de Paula Peixoto <tiago@skewed.de>
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
On 28.01.2015 10:26, graph-tool@v6y.net wrote:
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
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 -- Tiago de Paula Peixoto <tiago@skewed.de>
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
On 28.01.2015 19:42, graph-tool@v6y.net wrote:
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.
Can you try the patch attached, and re-enable sparsehash? Best, Tiago -- Tiago de Paula Peixoto <tiago@skewed.de>
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
On 29.01.2015 01:04, graph-tool@v6y.net wrote:
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]
Is the GDB backtrace the same as before? Is the missing symbol also the same? Best, Tiago -- Tiago de Paula Peixoto <tiago@skewed.de>
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
On 29.01.2015 10:31, graph-tool@v6y.net wrote:
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:
The patch attached should finally take care of it. Could you please test it? Best, Tiago -- Tiago de Paula Peixoto <tiago@skewed.de>
On 29.01.2015 20:52, graph-tool@v6y.net wrote:
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.
The modifications are now in the git version. Best, Tiago -- Tiago de Paula Peixoto <tiago@skewed.de>
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" previously, it would almost always time-out, therefore we are currently using the github repo in portage. -Justin
On 29.01.2015 23:32, graph-tool@v6y.net wrote:
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"
previously, it would almost always time-out, therefore we are currently using the github repo in portage.
This has been fixed now. You can go back using the official repository. Best, Tiago -- Tiago de Paula Peixoto <tiago@skewed.de>
participants (2)
-
graph-tool＠v6y.net -
Tiago de Paula Peixoto