STP Crash On Start

[Noomene Ben Henda]

Hi,

I have just finished installing STP following the instructions. Everything seemed normal until I start the program

>stp
Illegal instruction (core dumped)

Below I have included a gdb trace. Any idea?

Any help is appreciated

Regards
/noomene

>gdb /usr/local/bin/stp core
GNU gdb (GDB) 7.5.91.20130417-cvs-ubuntu
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/local/bin/stp...done.
[New LWP 14316]

warning: Can't read pathname for load map: Input/output error.
Core was generated by `stp'.
Program terminated with signal 4, Illegal instruction.
#0 0x08056ea3 in std::vector<__gnu_cxx::_Hashtable_node<std::pair<BEEV::ASTNode const, BEEV::ASTNode> >*, std::allocator<__gnu_cxx::_Hashtable_node<std::pair<BEEV::ASTNode const, BEEV::ASTNode> >*> >::_M_fill_insert(__gnu_cxx::__normal_iterator<__gnu_cxx::_Hashtable_node<std::pair<BEEV::ASTNode const, BEEV::ASTNode> >**, std::vector<__gnu_cxx::_Hashtable_node<std::pair<BEEV::ASTNode const, BEEV::ASTNode> >*, std::allocator<__gnu_cxx::_Hashtable_node<std::pair<BEEV::ASTNode const, BEEV::ASTNode> >*> > >, unsigned int, __gnu_cxx::_Hashtable_node<std::pair<BEEV::ASTNode const, BEEV::ASTNode> >* const&) ()
(gdb) bt
#0 0x08056ea3 in std::vector<__gnu_cxx::_Hashtable_node<std::pair<BEEV::ASTNode const, BEEV::ASTNode> >*, std::allocator<__gnu_cxx::_Hashtable_node<std::pair<BEEV::ASTNode const, BEEV::ASTNode> >*> >::_M_fill_insert(__gnu_cxx::__normal_iterator<__gnu_cxx::_Hashtable_node<std::pair<BEEV::ASTNode const, BEEV::ASTNode> >**, std::vector<__gnu_cxx::_Hashtable_node<std::pair<BEEV::ASTNode const, BEEV::ASTNode> >*, std::allocator<__gnu_cxx::_Hashtable_node<std::pair<BEEV::ASTNode const, BEEV::ASTNode> >*> > >, unsigned int, __gnu_cxx::_Hashtable_node<std::pair<BEEV::ASTNode const, BEEV::ASTNode> >* const&) ()
#1 0x080b059c in __gnu_cxx::hash_map<BEEV::ASTNode, BEEV::ASTNode, BEEV::ASTNode::ASTNodeHasher, BEEV::ASTNode::ASTNodeEqual, std::allocator<BEEV::ASTNode> >::hash_map() ()
#2 0x0804ec37 in _GLOBAL__sub_I__ZN7printer13NodeLetVarMapE ()
#3 0x081fcd12 in __libc_csu_init ()
#4 0x401998ca in __libc_start_main () from /lib/i386-linux-gnu/libc.so.6
#5 0x08050cb9 in _start ()

[vg]

Hi,

It is strange that STP would crash like that. Did you actually compile it on your machine. I just compiled it, and see no problems from my side.

-Vijay Ganesh.

[Noomene Ben Henda]

Hi,

 

I checked it out and followed the instructions. It seems to compile and install properly with no errors. I tried many times first on Ubuntu (64) and now I am running Xubuntu (32). I get the same crash. I don't know, I provide below, for what it is worth, the output of some commands on my side. I hope you don't mind comparing the output on your side.

 

> uname -a

Linux noamen-VB 3.8.0-22-generic #33-Ubuntu SMP Thu May 16 15:17:59 UTC 2013 i686 i686 i686 GNU/Linux

 

> which stp | argx ldd

 linux-gate.so.1 =>  (0xb76ec000)
 libstdc++.so.6 => /usr/lib/i386-linux-gnu/libstdc++.so.6 (0xb75f0000)
 libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xb75ad000)
 libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xb758f000)
 libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb73dc000)
 /lib/ld-linux.so.2 (0xb76ed000)

 

Regards

/Noomene

[Stephen McCamant]

On Tuesday, June 4, 2013 9:37:53 AM UTC-5, Noomene Ben Henda wrote:

Hi,

 

I checked it out and followed the instructions. It seems to compile and install properly with no errors. I tried many times first on Ubuntu (64) and now I am running Xubuntu (32). I get the same crash. I don't know, I provide below, for what it is worth, the output of some commands on my side. I hope you don't mind comparing the output on your side.

Like Vijay, I wasn't able to reproduce the failure by compiling the SVN trunk on what I think is my most similar machine, an Atom laptop running 32-bit Ubuntu 13.04. I don't have a very specific theory about what might be going wrong, but I can offer some suggestions along the lines of "things to try".
 

> uname -a

Linux noamen-VB 3.8.0-22-generic #33-Ubuntu SMP Thu May 16 15:17:59 UTC 2013 i686 i686 i686 GNU/Linux

smcc% uname -a
Linux clerihew 3.8.0-23-generic #34-Ubuntu SMP Wed May 29 20:24:54 UTC 2013 i686 i686 i686 GNU/Linux
 

> which stp | argx ldd

 linux-gate.so.1 =>  (0xb76ec000)
 libstdc++.so.6 => /usr/lib/i386-linux-gnu/libstdc++.so.6 (0xb75f0000)
 libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xb75ad000)
 libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xb758f000)
 libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb73dc000)
 /lib/ld-linux.so.2 (0xb76ed000)

"argx" isn't a standard command, is it? I'm presuming from context your command is equivalent to "ldd $(which stp)"

smcc% ldd bin/stp
    linux-gate.so.1 =>  (0xb7728000)
    libstdc++.so.6 => /usr/lib/i386-linux-gnu/libstdc++.so.6 (0xb761f000)
    libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xb75dc000)
    libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xb75be000)
    libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb740b000)
    /lib/ld-linux.so.2 (0xb7729000)

Neither of these seem very informative, IMO. I think the most likely software to be causing this incompatibility would be your G++ compiler, maybe followed by the libstdc++ library. If you're using the default versions that come with your Ubuntu distribution, the easiest way to specify that information would be to give that distribution version. (From your kernel version, 13.04 seems most likely to me). "g++ --version" might be a good sanity check too.

smcc% cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=13.04
DISTRIB_CODENAME=raring
DISTRIB_DESCRIPTION="Ubuntu 13.04"

smcc% g++ --version
g++ (Ubuntu/Linaro 4.7.3-1ubuntu1) 4.7.3

"Illegal instruction" is a weird kind of crash to get from a source-level bug, and the fact that it's coming inside the expansion of an STL template also makes it seem less likely that it's a bug in STP proper.

The most useful piece of information to get out of the crash for an illegal instruction would be the instruction that's causing the fault. The GDB command for that would be "x/i $eip" at the point of the crash. If this is gibberish rather than a real instruction, the problem is a wild jump. If it's an instruction that's generally valid, but not supported by your processor, there's a code generation problem. If it looks like a perfectly valid instruction, then something else weird is going on.

If it's a processor support issue, it would be useful to know what kind of processor your system has. Compare:

smcc% cat /proc/cpuinfo | fgrep "model name" | head -1
model name    : Intel(R) Atom(TM) CPU N550   @ 1.50GHz

Also, is there a virtual machine involved, or are you running the software on a different machine than you compiled it on?

STP's default compile options include "-march=native", which tells G++ to generate code using any instructions supported by the machine it's compiling on. This generally maximizes performance, but it means the binaries won't work if you move them to a system with a less-featureful CPU. So you can try recompiling without that option. You could also try removing the other optimization options "-O3" and "-fomit-frame-pointer", though they seem less likely to be implicated.

Even more generic suggestions:

Run the program under Valgrind and see if it gives any more informative errors.

Do you see the same failure with older SVN revisions? If an old version works, use binary search to find the change that triggered the problem.

Hope this helps,

 -- Stephen

[Noomene Ben Henda]

Hi,

My original reply is lost. The thing is that the problem is now solved and I was unable to reproduce the crash. I am hereby trying to remember my lost answers.

On Thursday, June 6, 2013 12:53:25 AM UTC+2, Stephen McCamant wrote:

On Tuesday, June 4, 2013 9:37:53 AM UTC-5, Noomene Ben Henda wrote:

Hi,

 

I checked it out and followed the instructions. It seems to compile and install properly with no errors. I tried many times first on Ubuntu (64) and now I am running Xubuntu (32). I get the same crash. I don't know, I provide below, for what it is worth, the output of some commands on my side. I hope you don't mind comparing the output on your side.

Like Vijay, I wasn't able to reproduce the failure by compiling the SVN trunk on what I think is my most similar machine, an Atom laptop running 32-bit Ubuntu 13.04. I don't have a very specific theory about what might be going wrong, but I can offer some suggestions along the lines of "things to try".
 

> uname -a

Linux noamen-VB 3.8.0-22-generic #33-Ubuntu SMP Thu May 16 15:17:59 UTC 2013 i686 i686 i686 GNU/Linux

smcc% uname -a
Linux clerihew 3.8.0-23-generic #34-Ubuntu SMP Wed May 29 20:24:54 UTC 2013 i686 i686 i686 GNU/Linux
 

> which stp | argx ldd

 linux-gate.so.1 =>  (0xb76ec000)
 libstdc++.so.6 => /usr/lib/i386-linux-gnu/libstdc++.so.6 (0xb75f0000)
 libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xb75ad000)
 libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xb758f000)
 libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb73dc000)
 /lib/ld-linux.so.2 (0xb76ed000)

"argx" isn't a standard command, is it? I'm presuming from context your command is equivalent to "ldd $(which stp)"

I am not sure. It is in my dist.

smcc% ldd bin/stp
    linux-gate.so.1 =>  (0xb7728000)
    libstdc++.so.6 => /usr/lib/i386-linux-gnu/libstdc++.so.6 (0xb761f000)
    libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xb75dc000)
    libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xb75be000)
    libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb740b000)
    /lib/ld-linux.so.2 (0xb7729000)

Neither of these seem very informative, IMO. I think the most likely software to be causing this incompatibility would be your G++ compiler, maybe followed by the libstdc++ library. If you're using the default versions that come with your Ubuntu distribution, the easiest way to specify that information would be to give that distribution version. (From your kernel version, 13.04 seems most likely to me). "g++ --version" might be a good sanity check too.

smcc% cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=13.04
DISTRIB_CODENAME=raring
DISTRIB_DESCRIPTION="Ubuntu 13.04"

DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=13.04
DISTRIB_CODENAME=raring
DISTRIB_DESCRIPTION="Ubuntu 13.04"

smcc% g++ --version
g++ (Ubuntu/Linaro 4.7.3-1ubuntu1) 4.7.3

 g++ (Ubuntu/Linaro 4.7.3-1ubuntu1) 4.7.3

"Illegal instruction" is a weird kind of crash to get from a source-level bug, and the fact that it's coming inside the expansion of an STL template also makes it seem less likely that it's a bug in STP proper.

Indeed

The most useful piece of information to get out of the crash for an illegal instruction would be the instruction that's causing the fault. The GDB command for that would be "x/i $eip" at the point of the crash. If this is gibberish rather than a real instruction, the problem is a wild jump. If it's an instruction that's generally valid, but not supported by your processor, there's a code generation problem. If it looks like a perfectly valid instruction, then something else weird is going on.

I run it in Valgrind which stopped with "unhandled instruction". The instruction in question is a "vmovd (0xC5)" with an "xmm0" in one of the operands (if I recall correctly).
Enabling VT-x in the BIOS (which was disabled by default on my machine) mad it work.

If it's a processor support issue, it would be useful to know what kind of processor your system has. Compare:

smcc% cat /proc/cpuinfo | fgrep "model name" | head -1
model name    : Intel(R) Atom(TM) CPU N550   @ 1.50GHz

model name    : Intel(R) Core(TM) i5-3320M CPU @ 2.60GHz

Also, is there a virtual machine involved, or are you running the software on a different machine than you compiled it on?

Yes I am running Xubuntu on Oracle's VirtualBox on a Windows 7 host.

STP's default compile options include "-march=native", which tells G++ to generate code using any instructions supported by the machine it's compiling on. This generally maximizes performance, but it means the binaries won't work if you move them to a system with a less-featureful CPU. So you can try recompiling without that option. You could also try removing the other optimization options "-O3" and "-fomit-frame-pointer", though they seem less likely to be implicated.

Removing this option made it work.

Even more generic suggestions:

Run the program under Valgrind and see if it gives any more informative errors.

See above.

Do you see the same failure with older SVN revisions? If an old version works, use binary search to find the change that triggered the problem.

Didn't bother trying since the problem is solved.

Hope this helps,

Thnaks

 -- Stephen

/Noamen

[Stephen McCamant]

>>>>> "NBH" == Noomene Ben Henda <noo...@gmail.com> writes:

NBH> Hi,
NBH> My original reply is lost. The thing is that the problem is now
NBH> solved and I was unable to reproduce the crash. I am hereby
NBH> trying to remember my lost answers.

[...]

SMcC> The most useful piece of information to get out of the crash for
SMcC> an illegal instruction would be the instruction that's causing
SMcC> the fault. The GDB command for that would be "x/i $eip" at the
SMcC> point of the crash. If this is gibberish rather than a real
SMcC> instruction, the problem is a wild jump. If it's an instruction
SMcC> that's generally valid, but not supported by your processor,
SMcC> there's a code generation problem. If it looks like a perfectly
SMcC> valid instruction, then something else weird is going on.

NBH> I run it in Valgrind which stopped with "unhandled
NBH> instruction". The instruction in question is a "vmovd (0xC5)"
NBH> with an "xmm0" in one of the operands (if I recall correctly).
NBH> Enabling VT-x in the BIOS (which was disabled by default on my
NBH> machine) mad[e] it work.

SMcC> % cat /proc/cpuinfo | fgrep "model name" | head -1

NBH> model name : Intel(R) Core(TM) i5-3320M CPU @ 2.60GHz

SMcC> Also, is there a virtual machine involved, or are you running
SMcC> the software on a different machine than you compiled it on?

NBH> Yes I am running Xubuntu on Oracle's VirtualBox on a Windows 7
NBH> host.

"vmovd" is an AVX instruction (listed under "MOVD/MOVQ" in the Intel
manual), which is supported by your Ivy Bridge CPU, so I think we can
conclude that VirtualBox is at fault here. And in fact if you Google
"VirtualBox AVX" you'll see that missing AVX support is a known
limitation of VirtualBox. I would guess it's something that they'll
get around to fixing at some point in the future, but for now it
sounds like you've found suitable workarounds.

--- Stephen