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

[Nick Foster]

Sorry, should have sent to list. Putting it here so it's on record as solved.

--n

---

From: address@hidden
To: address@hidden
Subject: RE: [Discuss-gnuradio] boost::thread_resource_error in gr-pager
Date: Mon, 15 Sep 2008 00:03:30 +0000

Thanks Eric. Decreasing max stack space did the trick.

--n

---

> Date: Sun, 14 Sep 2008 15:05:55 -0700
> From: address@hidden
> To: address@hidden
> CC: address@hidden
> Subject: Re: [Discuss-gnuradio] boost::thread_resource_error in gr-pager
>
> 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

---

Want to do more with Windows Live? Learn “10 hidden secrets” from Jamie. Learn Now

---

Get more out of the Web. Learn 10 hidden secrets of Windows Live. Learn Now