bluespec.com Forum Index bluespec.com
Bluespec Forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Segmentation Fault
Goto page 1, 2  Next
 
Post new topic   Reply to topic    bluespec.com Forum Index -> Tools: Bluesim
View previous topic :: View next topic  
Author Message
nharvey



Joined: 19 Aug 2010
Posts: 11

PostPosted: Thu Jun 25, 2015 12:21 am    Post subject: Segmentation Fault Reply with quote

Hello,

I have just tried to upgrade to version 2014.07.A, previously I was using 2011.06.D.

When I try to run a generated simulator I get a Segmentation Fault.

I am using the following commands to generate the simulator:
bsc -sim -u -g mkTb hello_world.bsv
bsc -sim -e mkTb -o ./out
./out

The bsv code is just the first "hello world" example pulled from BSV by example.

Has something changed with the build procedure and flags that I have missed? Or have I followed the wrong procedure while moving to the new version?
Back to top
View user's profile Send private message
quark
Site Admin


Joined: 02 Nov 2007
Posts: 500

PostPosted: Thu Jun 25, 2015 12:20 pm    Post subject: Re: Segmentation Fault Reply with quote

This is not an issue that we've seen before. It may be caused by something in the OS environment that you're running on. Let me give you some steps for debugging.

First of all, I suspect that it's not really a segfault, it's just an ordinary error (probably with a helpful error message), but it is being reported as a segfault because it occurs inside a script. Many of the Bluespec commands that you run are not to actual programs, but are just scripts that figure out whether you're running on 32-bit or 64-bit, set some environment variables, and then call the actual program in $BLUESPECDIR/bin/linux32 or linux64, as appropriate. We have observed that in some environments, if the actual program encounters a system error -- such as running out of memory -- that error is treated as a segfault, rather than reporting the actual problem, which is not so helpful.

The other thing to note is that when you run "./out", that's also a script. Open the contents and you'll see that it is calling "bluetcl". Bluetcl is a TCL shell that has been extended with new commands for working with Bluespec designs. It is also how Bluesim is implemented: the BSC compilation generates a shared object file (.o) for the design, which Bluetcl can load using the "sim load" command, and then Bluetcl can run the model using other commands like "sim run".

So, the first thing to do is to see whether you can run "bluetcl". What happens when you just run this on the command line:
Code:
bluetcl

Does that also encounter a segfault? I suspect it might. If it does, then we can get at the real error by running the "bluetcl" program directly, and not through a wrapper, with these commands:
Code:
# setenv LD_LIBRARY_PATH ${BLUESPECDIR}/SAT/g++4_64/
# ${BLUESPECDIR}/bin/linux64/bluetcl

Or, if you're running on 32-bit system:
Code:
# setenv LD_LIBRARY_PATH ${BLUESPECDIR}/SAT/g++4/
# ${BLUESPECDIR}/bin/linux32/bluetcl

Try those and let me know what happens. If that doesn't reveal the error, then we can keep going with the diagnosis.
Back to top
View user's profile Send private message
nharvey



Joined: 19 Aug 2010
Posts: 11

PostPosted: Sun Jun 28, 2015 9:11 pm    Post subject: Reply with quote

Hello,

bluetcl seems to run correctly. It provides a prompt ie:
[@localhost ~]$ bluetcl
%

The version of BSV that I am using Bluespec-2014.07.A only has a single bin folder, there isn't a /bin/linux32 or /bin/linux64
Back to top
View user's profile Send private message
quark
Site Admin


Joined: 02 Nov 2007
Posts: 500

PostPosted: Mon Jun 29, 2015 3:45 pm    Post subject: Reply with quote

Yes, there is a "bin/" directory at the top of the Bluespec files. But you don't actually need that directory. Everything in there is just a script that calls the same name in "lib/bin/". That's what I mean by "${BLUESPECDIR}/bin" -- remember that BLUESPECDIR is the path to the "lib/" subdirectory, not the top directory of the Bluespec files. If you look in "lib/bin/", you should see "linux32" and "linux64" subdirectories.

Ok, so if bluetcl works then the next step will be to try running it without the wrapper script. If you look at the contents of "out", you will see that it runs a command like this (where "mkMod" would be replaced by the top module in your design, and the creation time is a timestamp that will vary):
Code:
exec $BLUESPECDIR/tcllib/bluespec/bluesim.tcl $0.so mkMod --script_name `basename $0` --creation_time 1433180527 "[email protected]"

This is executing "bluesim.tcl" which is a Bluetcl script that can be found in the Bluespec release. You can look inside the script to see what it's doing, although it's a bit convoluted, so I can spare you the effort. Essentially, the script is calling these commands inside Bluetcl:
Code:
Bluesim::sim load <object_file> <top_module_name>
Bluesim::sim run

So what you can do is this: First, run bluetcl without a wrapper:
Code:
# setenv LD_LIBRARY_PATH ${BLUESPECDIR}/SAT/g++4_64/
# ${BLUESPECDIR}/bin/linux64/bluetcl

Then, at the Bluetcl prompt, run these commands:
Code:
% Bluesim::sim load out.so mkTopMod
% Bluesim::sim run

If you do that, do you still see a segfault, or do you get a better error message?
Back to top
View user's profile Send private message
nharvey



Joined: 19 Aug 2010
Posts: 11

PostPosted: Thu Jul 02, 2015 1:52 am    Post subject: Reply with quote

Sorry to go back a step, my previous post wasn't clear. If I run bluetcl from the command line directly it loads into a prompt, via opening /tools/Bluespec-2014.07.A/bin/bluetcl

If I instead try open it directly as suggested then I get the following error:
Code:
 ${BLUESPECDIR}/bin/linux32/bluetcl
/tools/Bluespec-2014.07.A/lib/bin/linux32/bluetcl: error while loading shared libraries: libyices.so.2: cannot open shared object file: No such file or directory
Back to top
View user's profile Send private message
quark
Site Admin


Joined: 02 Nov 2007
Posts: 500

PostPosted: Thu Jul 02, 2015 11:08 am    Post subject: Reply with quote

Before opening it directly, did you set this environment variable:
Code:
setenv LD_LIBRARY_PATH ${BLUESPECDIR}/SAT/g++4/

The missing shared object file (libyices.so.2) can be found in that directory. But by default, your system doesn't know to look there, so you have to set LD_LIBRARY_PATH to point to where it can find it. That's part of what the wrapper script does. Anyway, you should be able to confirm that the file exists in that directory:
Code:
ls ${BLUESPECDIR}/SAT/g++4/

That's the directory if you're using "linux32". If you're using "linux64", then you'd want to set LD_LIBRARY_PATH to point to the "g++4_64" subdirectory.
Back to top
View user's profile Send private message
nharvey



Joined: 19 Aug 2010
Posts: 11

PostPosted: Sun Jul 05, 2015 10:43 pm    Post subject: Reply with quote

It looks as if I have now set LD_LIBRARY_PATH correctly, it does seem to point to that folder, which contains the following files:
libstp.so.1 libyices.so.2 libyices.so.2.stub
Back to top
View user's profile Send private message
quark
Site Admin


Joined: 02 Nov 2007
Posts: 500

PostPosted: Mon Jul 06, 2015 11:49 am    Post subject: Reply with quote

So are you able to run bluetcl now?
Back to top
View user's profile Send private message
nharvey



Joined: 19 Aug 2010
Posts: 11

PostPosted: Wed Jul 08, 2015 11:26 pm    Post subject: Reply with quote

Hello,

Sorry my previous post wasn't clear, at the time I wasn't able to run it but now I am.

It seems as if it was an issue with using bash rather than csh (or export vs setenv). I am now able to run Bluetcl as instructed under csh.

To clear up some of my confustion, is Bluesim::sim with the rest as arguments or is the command or load the command while in Bluetcl?

If the first then I get the following:
% Bluesim::sim load out mkTb
invalid command name "Bluesim::sim"

While the second results in the following:
% load out.so mkTb
couldn't load file "out.so": out.so: cannot open shared object file: No such file or directory
% load ./out.so mkTb
couldn't find procedure Mktb_Init

Thank you.
Back to top
View user's profile Send private message
quark
Site Admin


Joined: 02 Nov 2007
Posts: 500

PostPosted: Thu Jul 09, 2015 10:45 am    Post subject: Reply with quote

My apologies. I should have recognized that the environment command would be different in different shells. Sorry about that.

And also, I forgot this command, which you'll need to run in 'bluetcl' so that the Bluesim set of commands are available:
Code:
% package require Bluesim

Sorry again. If you give that command first, then you will have access to the 'Bluesim::sim' command. The first argument to that command is a subcommand, like 'load'.

If you're curious, the built-in commands available in 'bluetcl' are documented in the BSC User Guide. The commands available in the Bluesim package are also documented there.
Back to top
View user's profile Send private message
nharvey



Joined: 19 Aug 2010
Posts: 11

PostPosted: Sun Jul 12, 2015 10:58 pm    Post subject: Reply with quote

Thanks for the info, I will have a look at the User guide.

When I try run the Bluesim::sim command then I get a Segmentation fault again:
${BLUESPECDIR}/bin/linux32/bluetcl
% package require Bluesim
1.0
% Bluesim::sim load out.so mkTb
Segmentation fault


quark wrote:
My apologies. I should have recognized that the environment command would be different in different shells. Sorry about that.

And also, I forgot this command, which you'll need to run in 'bluetcl' so that the Bluesim set of commands are available:
Code:
% package require Bluesim

Sorry again. If you give that command first, then you will have access to the 'Bluesim::sim' command. The first argument to that command is a subcommand, like 'load'.

If you're curious, the built-in commands available in 'bluetcl' are documented in the BSC User Guide. The commands available in the Bluesim package are also documented there.
Back to top
View user's profile Send private message
quark
Site Admin


Joined: 02 Nov 2007
Posts: 500

PostPosted: Mon Jul 13, 2015 1:46 pm    Post subject: Reply with quote

Well, that's very unusual. What operating system (and version) are you running on? If you run "uname -a", what output does it give?

The next step to try is to run 'gdb' and see if it can provide any information about where the segfault occurred. Run this command:
Code:
gdb ${BLUESPECDIR}/bin/linux32/bluetcl

and then at the prompt:
Code:
(gdb) run

That should start bluetcl and give you the '%' prompt, at which you can type the 'Bluesim::sim' commands.

Before you do that, though, you'll need to edit your .shrc file (or .cshrc or .tcshrc, in my case) to include the 'set' (or 'setenv') command for LD_LIBRARY_PATH. The way that 'gdb' works, it doesn't use your current environment, it uses a fresh shell environment. So setting LD_LIBRARY_PATH in your environment won't make it visible to the program that 'gdb' runs. You need to add the command the to your .shrc file that will get run when 'gdb' opens a new shell.

If you do all that, does 'gdb' catch the segfault? If you then run this command:
Code:
(gdb) bt

what output does it give?
Back to top
View user's profile Send private message
quark
Site Admin


Joined: 02 Nov 2007
Posts: 500

PostPosted: Mon Jul 13, 2015 2:14 pm    Post subject: Reply with quote

I just noticed that it's during the "load" step that you get the error. This step dynamically loads the .so object file. A segfault could occur if the .so is in some way incompatible with the 'bluetcl' program.

One thing we can look at is the libraries that each expects to find. There may be a mismatch there. What output do you get when you run these commands:
Code:
# ldd out.so
# ldd ${BLUESPECDIR}/bin/linux32/bluetcl
# ldd ${BLUESPECDIR}/SAT/g++4/libstp.so.1

The ABI of the C++ compiler that you're using could also be the problem. In earlier releases, we supported C++ ABIs of version 3 and 4. In the 2014 release, we now only support version 4. To check your version, run this command:
Code:
${BLUESPECDIR}/bin/bsenv c++_family

If you have any problem running that command, we can also get the information manually. The 'bsenv' script determines your C++ ABI family by running the following command, which you can run and report back with the results:
Code:
# c++ --version

I suspect that might be the problem.

Finally, another issue that can sometimes happen is that the setup script from another EDA vendor might have set LD_LIBRARY_PATH to point to their local libraries, which can be inconsistent. When you set LD_LIBRARY_PATH, are you adding to the path, or are you replacing it with the Bluespec location? If you're adding, try replacing.
Back to top
View user's profile Send private message
nharvey



Joined: 19 Aug 2010
Posts: 11

PostPosted: Tue Jul 14, 2015 11:44 pm    Post subject: Reply with quote

Here are the results of those commands, could the permission issue be the cause or is it something else?

ldd out.so
linux-gate.so.1 => (0x00de0000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00ada000)
libm.so.6 => /lib/libm.so.6 (0x0069a000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00f13000)
libc.so.6 => /lib/libc.so.6 (0x00110000)
/lib/ld-linux.so.2 (0x002a5000)

ldd ${BLUESPECDIR}/bin/linux32/bluetcl
linux-gate.so.1 => (0x00c10000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00101000)
libyices.so.2 => not found
libstp.so.1 => not found
libX11.so.6 => /usr/lib/libX11.so.6 (0x07283000)
libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x0024f000)
libXft.so.2 => /usr/lib/libXft.so.2 (0x07c09000)
librt.so.1 => /lib/librt.so.1 (0x00dea000)
libutil.so.1 => /lib/libutil.so.1 (0x00793000)
libdl.so.2 => /lib/libdl.so.2 (0x00de4000)
libgmp.so.3 => /usr/lib/sse2/libgmp.so.3 (0x00b52000)
libm.so.6 => /lib/libm.so.6 (0x00dbb000)
libc.so.6 => /lib/libc.so.6 (0x0034b000)
/lib/ld-linux.so.2 (0x002a5000)
libXau.so.6 => /usr/lib/libXau.so.6 (0x001cf000)
libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00df5000)
libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x07388000)
libexpat.so.0 => /lib/libexpat.so.0 (0x0022c000)
libXrender.so.1 => /usr/lib/libXrender.so.1 (0x0747a000)

ldd ${BLUESPECDIR}/SAT/g++4/libstp.so.1
ldd: warning: you do not have execution permission for `/tools/Bluespec-2014.07.A/lib/SAT/g++4/libstp.so.1'
linux-gate.so.1 => (0x00131000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00132000)
libm.so.6 => /lib/libm.so.6 (0x00d74000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00110000)
libc.so.6 => /lib/libc.so.6 (0x00940000)
/lib/ld-linux.so.2 (0x002a5000)

${BLUESPECDIR}/bin/bsenv c++_family
g++4

I am replacing the LD_LIBRARY_PATH, currently it only points at the Bluespec location. We don't currently use the machine for anything else.
Back to top
View user's profile Send private message
quark
Site Admin


Joined: 02 Nov 2007
Posts: 500

PostPosted: Wed Jul 15, 2015 3:32 pm    Post subject: Reply with quote

Were you able to run "gdb" and give the "bt" command after the segfault? What was the output?

Also, what is the output of "uname -a". What kind of OS and file system are you running on?

You might also be able to identify the source of the segfault using 'strace'. Can you try running this command:
Code:
strace -f -o out.txt bluetcl

And then look in the 'out.txt' file to see if the segfault is mentioned, and if it gives a reason.

It's also curious that you get a permission warning when you run 'ldd' on the STP library. However, that ought to be unrelated. If you're running 'bsc' and 'bluetcl', that means that the STP was loaded, because they require STP on startup.

Is it also possible that you are running some sort of security module (e.g., AppArmor, SELinux) which is preventing a library from being loaded? If so, then perhaps you added rules to allow the older BSC release to run, but new rules might be needed for the new release. (Such as allowing libstp.so -- but again, that seems OK.)

If nothing else, perhaps the release was corrupted when you downloaded it. The 'md5sum' should be:
Code:
# md5sum Bluespec-2014.07.A.tar.gz
fb317851ad7573871837947ed19d7313

Or perhaps there was an issue when you unpacked the tar-ball onto your file system. That can happen with the symlinks for libyices in the lib/SAT/g++*/ directories, if the file system has problems with symlinks, but that doesn't appear to be your issue here.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    bluespec.com Forum Index -> Tools: Bluesim All times are GMT - 4 Hours
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum
bluespec.com topic RSS feed 


Powered by phpBB © 2001, 2005 phpBB Group
Protected by Anti-Spam ACP