discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] boost::thread_resource_error in gr-pager


From: Eric Blossom
Subject: Re: [Discuss-gnuradio] boost::thread_resource_error in gr-pager
Date: Sun, 14 Sep 2008 15:05:55 -0700
User-agent: Mutt/1.5.17 (2007-11-01)

On Sun, Sep 14, 2008 at 08:00:01PM +0000, Nick Foster wrote:
> Hi all,

> Hoping this isn't a naive question. I'm running into Boost errors
> when attempting to run the FLEX decoder, specifically the
> multithreaded instances (usrp_flex_all.py and
> usrp_flex_band.py). Here's the output:

> address@hidden:~/gnuradio/gr-pager/src$ ./usrp_flex_band.py -R A -g 32 -c 
> 13e3 
>>> gr_fir_fff: using SSE 
> terminate called after throwing an instance of 'boost::thread_resource_error' 
> what():
> boost::thread_resource_error Aborted

> So, Boost can't allocate a thread, or a mutex, or a lock, or
> something. It's a pretty ambiguous error.

This particular app has about 525 blocks.  
I'm guessing it's exceeding the total limit for stack space in a process.

First check what

  $ ulimit -a

shows.  Then try setting -s to something smaller, say 4096,

  $ ulimit -s 4094

then try running usrp_flex_band.py again.


> I've read that similar
> errors occur when the target application is compiled without
> pthreads, but that's definitely not the case (in fact, the makefile
> appears to include the -pthreads option twice). I'm running Boost
> 1.36.0, as recommended, and installed in /opt/boost_1_36_0/ as
> indicated in README.building-boost. It was built from source. The
> one (possibly) related issue is that, when make-ing Gnuradio, I had
> to provide a symbolic link to:

> /opt/boost_1_36_0/lib/libboost_thread-gcc42-mt-1_36.so.1.36.0

> from:

> /usr/lib/libboost_thread-gcc42-mt-1_36.so.1.36.0

This is strange.  It looks like somebody tried to install boost
into the system path, but didn't use the --layout=system option.  If
this sounds like something you may have done (perhaps by forgetting to
specify the --prefix option to boost when building it the first time),

  rm /usr/local/libboot*-gcc42-mt*.so*

> in order to get it to compile without errors, even though I provided
> --with-boost=/opt/boost_1_36_0/ to the configure script (I believe
> the compile failed somewhere in gruel).

Did you export LD_LIBRARY_PATH?

> This is on CVS revision 9420 (25 Aug 2008). I'm running Ubuntu Hardy
> Heron, if that gives any clues. I'm assuming this is simply a Boost
> installation problem, but I'm unable to find helpful information
> anywhere else.

Eric




reply via email to

[Prev in Thread] Current Thread [Next in Thread]