Re: [USRP-users] meta-ettus-v4.0.0.0 segfault

2021-01-13 Thread Philip Balister via USRP-users 
I haven't :( I have been looking at packaged testing for volk and
gnuradio. Once I have this sorted, I'll spend a little time looking into
setting this up for fftw to try and catch this problem faster in the future.

Philip

On 1/9/21 3:29 PM, Ben Magistro via USRP-users wrote:
> Finally getting a chance to circle back to this and I would rather be on
> dunfell but the bsp for the E310 doesn't appear to have been ported yet.  I
> made an attempt but cannot build an image successfully and need to do a
> better set of diffs on the kernel patches.
> 
> Has anyone else started on a dunfell port?
> 
> Ben
> 
> 
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> 

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] meta-ettus-v4.0.0.0 segfault

2021-01-09 Thread Ben Magistro via USRP-users 
Finally getting a chance to circle back to this and I would rather be on
dunfell but the bsp for the E310 doesn't appear to have been ported yet.  I
made an attempt but cannot build an image successfully and need to do a
better set of diffs on the kernel patches.

Has anyone else started on a dunfell port?

Ben
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] meta-ettus-v4.0.0.0 segfault

2020-12-12 Thread Philip Balister via USRP-users 
On 12/11/20 4:49 PM, Philip Balister via USRP-users wrote:
> On 12/6/20 10:03 AM, Ron Economos via USRP-users wrote:
>> Unfortunately, that FFTW bug has been around for a while. Issue 213 is a
>> duplicate of issue 182 from a year+ ago.
>>
>> https://github.com/FFTW/fftw3/issues/182
>>
>> On Ubuntu 20.04 armhf, they're just compiling the FFTW package without
>> NEON enabled.
> 
> I poked at this way more than I should have and am 99% certain the issue
> in in gcc-8. Building with -O off led to an fftw that would pass its
> make check. I tried a build on a qemuarm from OE/master and that worked
> (gcc-10). gcc-9 is a question, I fired up a build of OE/dunfell (gcc-9)
> and will run the qemu check and see what happens.

In the bad news, fftw qa tests fail in qemuarm with gcc9.

Philip

> 
> If you are stuck on zeus, you'll need to try and id the patch that fixes
> gcc and apply it to the gcc build. But getting off zeus would be a
> really bood move as it is out of support now.
> 
> Philip
> 
>>
>> Ron
>>
>> On 12/6/20 06:27, Ben Magistro via USRP-users wrote:
>>> Issue appears to be with the compiler that is included in Zeus (gcc
>>> 9.x vs 8.x) and an interaction with fftw. There is an open issue with
>>> fftw (https://github.com/FFTW/fftw3/issues/213) and a request to the
>>> yocto folks to request they consider adding back gcc-8.3 to zeus +
>>> dunfell (https://bugzilla.yoctoproject.org/show_bug.cgi?id=14144)
>>> until this can be better resolved.  I think data point 3 confirms this
>>> as I did not include options to enable neon when I compiled.
>>>
>>> On Wed, Nov 11, 2020 at 1:39 PM Ben Magistro >> > wrote:
>>>
>>>     Adding some more data points.
>>>
>>>     1) I've been trying to rebuild meta-ettus-v4 with debug enabled
>>>     but am hitting an issue with image size and can't seem to get past
>>>     that.  It says I should increase `MENDER_STORAGE_TOTAL_SIZE_MB` if
>>>     the actual size is larger but increasing this seems to have no
>>>     effect.  I am using the ettus docker image for oe-builder with the
>>>     command `./meta-ettus/contrib/build_imgs_package.sh e310_sg3
>>>     v4.0.0.0`.  For the debug portion I've added a few lines to
>>>     `build/conf/local.conf` to add the packages. I'm open to
>>>     suggestions to build the image with debug symbols and provide
>>>     additional feedback.
>>>
>>>     2) I put together a simple flowgraph, UHD source --> frequency
>>>     xlating fft --> null sink.  This also segfaults, no guarantees
>>>     that I got the parameters correct.
>>>
>>>     3) Since the issues seem to be with fftw, I decided to try
>>>     building my own copy of fftw mostly to get debug symbols and
>>>     continue troubleshooting.  For this I used `./configure
>>>     --enable-debug --enable-shared --enable-threads --enable-float`
>>>     and `make CFLAGS="-ggdb"`.  These options are best guesses right
>>>     now since I didn't look at the layers to see what parameters it is
>>>     using (assuming it is in one of the layers).  Using this build
>>>     with `export LD_LIBRARY_PATH=/usr/local/lib/` I do not get a
>>>     segfault with gr-ais or the above flowgraph but I also don't get
>>>     the expected output which makes me question the parameters I used
>>>     to build it.  Output wise I get a string of "D" or "O" to the
>>> console.
>>>
>>>     Thanks
>>>
>>>     Ben
>>>
>>>     On Thu, Nov 5, 2020 at 9:22 AM Michael Dickens
>>>     mailto:michael.dick...@ettus.com>> wrote:
>>>
>>>     Hi Ben - This issue has been reported to R&D internally. If
>>>     you wish to create a public-facing UHD issue on our Github
>>>     tracker please go ahead & do so, and tag me on it so that we
>>>     can keep track of it internally. - MLD
>>>
>>>     On Wed, Nov 4, 2020 at 11:25 PM Ben Magistro via USRP-users
>>>     >>     > wrote:
>>>
>>>     Is anyone else using meta-ettus-v4.0.0.0 yet?  if so, have
>>>     you had any issues with libfftw?
>>>
>>>     Using the image on an E310, adding a single OOT module
>>>     (gr-ais) and trying to run an app distributed with it, the
>>>     app segfaults.  To further troubleshoot, I added gdb and
>>>     it comes back with the following.  I have a separate
>>>     development host that has gnuradio 3.8 setup using pybombs
>>>     and do not experience this issue there.
>>>
>>>     Thread 1 "python3" received signal SIGSEGV, Segmentation
>>>     fault.
>>>     0xb6947836 in ?? () from /usr/lib/libfftw3f.so.3
>>>
>>>     To compile, I've needed to override PYTHON_EXECUTABLE as
>>>     it points to a non-existent path in /home/oe-builder
>>>     in /usr/lib/cmake/gnuradio/GnuradioConfig.cmake. To run I
>>>     also needed to define LD_EXPORT_PATH pointing to
>>>     /usr/local/lib/.
>>>
>>>     Thanks in advance.

Re: [USRP-users] meta-ettus-v4.0.0.0 segfault

2020-12-11 Thread Philip Balister via USRP-users 
On 12/6/20 10:03 AM, Ron Economos via USRP-users wrote:
> Unfortunately, that FFTW bug has been around for a while. Issue 213 is a
> duplicate of issue 182 from a year+ ago.
> 
> https://github.com/FFTW/fftw3/issues/182
> 
> On Ubuntu 20.04 armhf, they're just compiling the FFTW package without
> NEON enabled.

I poked at this way more than I should have and am 99% certain the issue
in in gcc-8. Building with -O off led to an fftw that would pass its
make check. I tried a build on a qemuarm from OE/master and that worked
(gcc-10). gcc-9 is a question, I fired up a build of OE/dunfell (gcc-9)
and will run the qemu check and see what happens.

If you are stuck on zeus, you'll need to try and id the patch that fixes
gcc and apply it to the gcc build. But getting off zeus would be a
really bood move as it is out of support now.

Philip

> 
> Ron
> 
> On 12/6/20 06:27, Ben Magistro via USRP-users wrote:
>> Issue appears to be with the compiler that is included in Zeus (gcc
>> 9.x vs 8.x) and an interaction with fftw. There is an open issue with
>> fftw (https://github.com/FFTW/fftw3/issues/213) and a request to the
>> yocto folks to request they consider adding back gcc-8.3 to zeus +
>> dunfell (https://bugzilla.yoctoproject.org/show_bug.cgi?id=14144)
>> until this can be better resolved.  I think data point 3 confirms this
>> as I did not include options to enable neon when I compiled.
>>
>> On Wed, Nov 11, 2020 at 1:39 PM Ben Magistro > > wrote:
>>
>>     Adding some more data points.
>>
>>     1) I've been trying to rebuild meta-ettus-v4 with debug enabled
>>     but am hitting an issue with image size and can't seem to get past
>>     that.  It says I should increase `MENDER_STORAGE_TOTAL_SIZE_MB` if
>>     the actual size is larger but increasing this seems to have no
>>     effect.  I am using the ettus docker image for oe-builder with the
>>     command `./meta-ettus/contrib/build_imgs_package.sh e310_sg3
>>     v4.0.0.0`.  For the debug portion I've added a few lines to
>>     `build/conf/local.conf` to add the packages. I'm open to
>>     suggestions to build the image with debug symbols and provide
>>     additional feedback.
>>
>>     2) I put together a simple flowgraph, UHD source --> frequency
>>     xlating fft --> null sink.  This also segfaults, no guarantees
>>     that I got the parameters correct.
>>
>>     3) Since the issues seem to be with fftw, I decided to try
>>     building my own copy of fftw mostly to get debug symbols and
>>     continue troubleshooting.  For this I used `./configure
>>     --enable-debug --enable-shared --enable-threads --enable-float`
>>     and `make CFLAGS="-ggdb"`.  These options are best guesses right
>>     now since I didn't look at the layers to see what parameters it is
>>     using (assuming it is in one of the layers).  Using this build
>>     with `export LD_LIBRARY_PATH=/usr/local/lib/` I do not get a
>>     segfault with gr-ais or the above flowgraph but I also don't get
>>     the expected output which makes me question the parameters I used
>>     to build it.  Output wise I get a string of "D" or "O" to the
>> console.
>>
>>     Thanks
>>
>>     Ben
>>
>>     On Thu, Nov 5, 2020 at 9:22 AM Michael Dickens
>>     mailto:michael.dick...@ettus.com>> wrote:
>>
>>     Hi Ben - This issue has been reported to R&D internally. If
>>     you wish to create a public-facing UHD issue on our Github
>>     tracker please go ahead & do so, and tag me on it so that we
>>     can keep track of it internally. - MLD
>>
>>     On Wed, Nov 4, 2020 at 11:25 PM Ben Magistro via USRP-users
>>     >     > wrote:
>>
>>     Is anyone else using meta-ettus-v4.0.0.0 yet?  if so, have
>>     you had any issues with libfftw?
>>
>>     Using the image on an E310, adding a single OOT module
>>     (gr-ais) and trying to run an app distributed with it, the
>>     app segfaults.  To further troubleshoot, I added gdb and
>>     it comes back with the following.  I have a separate
>>     development host that has gnuradio 3.8 setup using pybombs
>>     and do not experience this issue there.
>>
>>     Thread 1 "python3" received signal SIGSEGV, Segmentation
>>     fault.
>>     0xb6947836 in ?? () from /usr/lib/libfftw3f.so.3
>>
>>     To compile, I've needed to override PYTHON_EXECUTABLE as
>>     it points to a non-existent path in /home/oe-builder
>>     in /usr/lib/cmake/gnuradio/GnuradioConfig.cmake. To run I
>>     also needed to define LD_EXPORT_PATH pointing to
>>     /usr/local/lib/.
>>
>>     Thanks in advance.
>>     ___
>>     USRP-users mailing list
>>     USRP-users@lists.ettus.com
>> 
>>    
>> http://lists.ettus.com/mailman/listinfo

Re: [USRP-users] meta-ettus-v4.0.0.0 segfault

2020-12-06 Thread Philip Balister via USRP-users 
On 12/6/20 10:03 AM, Ron Economos via USRP-users wrote:
> Unfortunately, that FFTW bug has been around for a while. Issue 213 is a
> duplicate of issue 182 from a year+ ago.

I wonder if the fix is similar to the problem mentioned for AVX in the
3.3.8 release notes:

http://www.fftw.org/release-notes.html

Philip

> 
> https://github.com/FFTW/fftw3/issues/182
> 
> On Ubuntu 20.04 armhf, they're just compiling the FFTW package without
> NEON enabled.
> 
> Ron
> 
> On 12/6/20 06:27, Ben Magistro via USRP-users wrote:
>> Issue appears to be with the compiler that is included in Zeus (gcc
>> 9.x vs 8.x) and an interaction with fftw. There is an open issue with
>> fftw (https://github.com/FFTW/fftw3/issues/213) and a request to the
>> yocto folks to request they consider adding back gcc-8.3 to zeus +
>> dunfell (https://bugzilla.yoctoproject.org/show_bug.cgi?id=14144)
>> until this can be better resolved.  I think data point 3 confirms this
>> as I did not include options to enable neon when I compiled.
>>
>> On Wed, Nov 11, 2020 at 1:39 PM Ben Magistro > > wrote:
>>
>>     Adding some more data points.
>>
>>     1) I've been trying to rebuild meta-ettus-v4 with debug enabled
>>     but am hitting an issue with image size and can't seem to get past
>>     that.  It says I should increase `MENDER_STORAGE_TOTAL_SIZE_MB` if
>>     the actual size is larger but increasing this seems to have no
>>     effect.  I am using the ettus docker image for oe-builder with the
>>     command `./meta-ettus/contrib/build_imgs_package.sh e310_sg3
>>     v4.0.0.0`.  For the debug portion I've added a few lines to
>>     `build/conf/local.conf` to add the packages. I'm open to
>>     suggestions to build the image with debug symbols and provide
>>     additional feedback.
>>
>>     2) I put together a simple flowgraph, UHD source --> frequency
>>     xlating fft --> null sink.  This also segfaults, no guarantees
>>     that I got the parameters correct.
>>
>>     3) Since the issues seem to be with fftw, I decided to try
>>     building my own copy of fftw mostly to get debug symbols and
>>     continue troubleshooting.  For this I used `./configure
>>     --enable-debug --enable-shared --enable-threads --enable-float`
>>     and `make CFLAGS="-ggdb"`.  These options are best guesses right
>>     now since I didn't look at the layers to see what parameters it is
>>     using (assuming it is in one of the layers).  Using this build
>>     with `export LD_LIBRARY_PATH=/usr/local/lib/` I do not get a
>>     segfault with gr-ais or the above flowgraph but I also don't get
>>     the expected output which makes me question the parameters I used
>>     to build it.  Output wise I get a string of "D" or "O" to the
>> console.
>>
>>     Thanks
>>
>>     Ben
>>
>>     On Thu, Nov 5, 2020 at 9:22 AM Michael Dickens
>>     mailto:michael.dick...@ettus.com>> wrote:
>>
>>     Hi Ben - This issue has been reported to R&D internally. If
>>     you wish to create a public-facing UHD issue on our Github
>>     tracker please go ahead & do so, and tag me on it so that we
>>     can keep track of it internally. - MLD
>>
>>     On Wed, Nov 4, 2020 at 11:25 PM Ben Magistro via USRP-users
>>     >     > wrote:
>>
>>     Is anyone else using meta-ettus-v4.0.0.0 yet?  if so, have
>>     you had any issues with libfftw?
>>
>>     Using the image on an E310, adding a single OOT module
>>     (gr-ais) and trying to run an app distributed with it, the
>>     app segfaults.  To further troubleshoot, I added gdb and
>>     it comes back with the following.  I have a separate
>>     development host that has gnuradio 3.8 setup using pybombs
>>     and do not experience this issue there.
>>
>>     Thread 1 "python3" received signal SIGSEGV, Segmentation
>>     fault.
>>     0xb6947836 in ?? () from /usr/lib/libfftw3f.so.3
>>
>>     To compile, I've needed to override PYTHON_EXECUTABLE as
>>     it points to a non-existent path in /home/oe-builder
>>     in /usr/lib/cmake/gnuradio/GnuradioConfig.cmake. To run I
>>     also needed to define LD_EXPORT_PATH pointing to
>>     /usr/local/lib/.
>>
>>     Thanks in advance.
>>     ___
>>     USRP-users mailing list
>>     USRP-users@lists.ettus.com
>> 
>>    
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>> ___
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> 
> 
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] meta-ettus-v4.0.0.0 segfault

2020-12-06 Thread Ron Economos via USRP-users 
Unfortunately, that FFTW bug has been around for a while. Issue 213 is a 
duplicate of issue 182 from a year+ ago.


https://github.com/FFTW/fftw3/issues/182

On Ubuntu 20.04 armhf, they're just compiling the FFTW package without 
NEON enabled.


Ron

On 12/6/20 06:27, Ben Magistro via USRP-users wrote:
Issue appears to be with the compiler that is included in Zeus (gcc 
9.x vs 8.x) and an interaction with fftw. There is an open issue with 
fftw (https://github.com/FFTW/fftw3/issues/213) and a request to the 
yocto folks to request they consider adding back gcc-8.3 to zeus + 
dunfell (https://bugzilla.yoctoproject.org/show_bug.cgi?id=14144) 
until this can be better resolved.  I think data point 3 confirms this 
as I did not include options to enable neon when I compiled.


On Wed, Nov 11, 2020 at 1:39 PM Ben Magistro > wrote:


Adding some more data points.

1) I've been trying to rebuild meta-ettus-v4 with debug enabled
but am hitting an issue with image size and can't seem to get past
that.  It says I should increase `MENDER_STORAGE_TOTAL_SIZE_MB` if
the actual size is larger but increasing this seems to have no
effect.  I am using the ettus docker image for oe-builder with the
command `./meta-ettus/contrib/build_imgs_package.sh e310_sg3
v4.0.0.0`.  For the debug portion I've added a few lines to
`build/conf/local.conf` to add the packages. I'm open to
suggestions to build the image with debug symbols and provide
additional feedback.

2) I put together a simple flowgraph, UHD source --> frequency
xlating fft --> null sink.  This also segfaults, no guarantees
that I got the parameters correct.

3) Since the issues seem to be with fftw, I decided to try
building my own copy of fftw mostly to get debug symbols and
continue troubleshooting.  For this I used `./configure
--enable-debug --enable-shared --enable-threads --enable-float`
and `make CFLAGS="-ggdb"`.  These options are best guesses right
now since I didn't look at the layers to see what parameters it is
using (assuming it is in one of the layers).  Using this build
with `export LD_LIBRARY_PATH=/usr/local/lib/` I do not get a
segfault with gr-ais or the above flowgraph but I also don't get
the expected output which makes me question the parameters I used
to build it.  Output wise I get a string of "D" or "O" to the console.

Thanks

Ben

On Thu, Nov 5, 2020 at 9:22 AM Michael Dickens
mailto:michael.dick...@ettus.com>> wrote:

Hi Ben - This issue has been reported to R&D internally. If
you wish to create a public-facing UHD issue on our Github
tracker please go ahead & do so, and tag me on it so that we
can keep track of it internally. - MLD

On Wed, Nov 4, 2020 at 11:25 PM Ben Magistro via USRP-users
mailto:usrp-users@lists.ettus.com>> wrote:

Is anyone else using meta-ettus-v4.0.0.0 yet?  if so, have
you had any issues with libfftw?

Using the image on an E310, adding a single OOT module
(gr-ais) and trying to run an app distributed with it, the
app segfaults.  To further troubleshoot, I added gdb and
it comes back with the following.  I have a separate
development host that has gnuradio 3.8 setup using pybombs
and do not experience this issue there.

Thread 1 "python3" received signal SIGSEGV, Segmentation
fault.
0xb6947836 in ?? () from /usr/lib/libfftw3f.so.3

To compile, I've needed to override PYTHON_EXECUTABLE as
it points to a non-existent path in /home/oe-builder
in /usr/lib/cmake/gnuradio/GnuradioConfig.cmake. To run I
also needed to define LD_EXPORT_PATH pointing to
/usr/local/lib/.

Thanks in advance.
___
USRP-users mailing list
USRP-users@lists.ettus.com 
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] meta-ettus-v4.0.0.0 segfault

2020-12-06 Thread Ben Magistro via USRP-users 
Issue appears to be with the compiler that is included in Zeus (gcc 9.x vs
8.x) and an interaction with fftw.  There is an open issue with fftw (
https://github.com/FFTW/fftw3/issues/213) and a request to the yocto folks
to request they consider adding back gcc-8.3 to zeus + dunfell (
https://bugzilla.yoctoproject.org/show_bug.cgi?id=14144) until this can be
better resolved.  I think data point 3 confirms this as I did not include
options to enable neon when I compiled.

On Wed, Nov 11, 2020 at 1:39 PM Ben Magistro  wrote:

> Adding some more data points.
>
> 1) I've been trying to rebuild meta-ettus-v4 with debug enabled but am
> hitting an issue with image size and can't seem to get past that.  It says
> I should increase `MENDER_STORAGE_TOTAL_SIZE_MB` if the actual size is
> larger but increasing this seems to have no effect.  I am using the ettus
> docker image for oe-builder with the command
> `./meta-ettus/contrib/build_imgs_package.sh e310_sg3 v4.0.0.0`.  For the
> debug portion I've added a few lines to `build/conf/local.conf` to add the
> packages.  I'm open to suggestions to build the image with debug symbols
> and provide additional feedback.
>
> 2) I put together a simple flowgraph, UHD source --> frequency xlating fft
> --> null sink.  This also segfaults, no guarantees that I got the
> parameters correct.
>
> 3) Since the issues seem to be with fftw, I decided to try building my own
> copy of fftw mostly to get debug symbols and continue troubleshooting.  For
> this I used `./configure --enable-debug --enable-shared --enable-threads
> --enable-float` and `make CFLAGS="-ggdb"`.  These options are best guesses
> right now since I didn't look at the layers to see what parameters it is
> using (assuming it is in one of the layers).  Using this build with `export
> LD_LIBRARY_PATH=/usr/local/lib/` I do not get a segfault with gr-ais or the
> above flowgraph but I also don't get the expected output which makes me
> question the parameters I used to build it.  Output wise I get a string of
> "D" or "O" to the console.
>
> Thanks
>
> Ben
>
> On Thu, Nov 5, 2020 at 9:22 AM Michael Dickens 
> wrote:
>
>> Hi Ben - This issue has been reported to R&D internally. If you wish to
>> create a public-facing UHD issue on our Github tracker please go ahead & do
>> so, and tag me on it so that we can keep track of it internally. - MLD
>>
>> On Wed, Nov 4, 2020 at 11:25 PM Ben Magistro via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Is anyone else using meta-ettus-v4.0.0.0 yet?  if so, have you had any
>>> issues with libfftw?
>>>
>>> Using the image on an E310, adding a single OOT module (gr-ais) and
>>> trying to run an app distributed with it, the app segfaults.  To further
>>> troubleshoot, I added gdb and it comes back with the following.  I have a
>>> separate development host that has gnuradio 3.8 setup using pybombs and do
>>> not experience this issue there.
>>>
>>> Thread 1 "python3" received signal SIGSEGV, Segmentation fault.
>>> 0xb6947836 in ?? () from /usr/lib/libfftw3f.so.3
>>>
>>> To compile, I've needed to override PYTHON_EXECUTABLE as it points to a
>>> non-existent path in /home/oe-builder in
>>> /usr/lib/cmake/gnuradio/GnuradioConfig.cmake.  To run I also needed to
>>> define LD_EXPORT_PATH pointing to /usr/local/lib/.
>>>
>>> Thanks in advance.
>>> ___
>>> USRP-users mailing list
>>> USRP-users@lists.ettus.com
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] meta-ettus-v4.0.0.0 segfault

2020-11-11 Thread Ben Magistro via USRP-users 
Adding some more data points.

1) I've been trying to rebuild meta-ettus-v4 with debug enabled but am
hitting an issue with image size and can't seem to get past that.  It says
I should increase `MENDER_STORAGE_TOTAL_SIZE_MB` if the actual size is
larger but increasing this seems to have no effect.  I am using the ettus
docker image for oe-builder with the command
`./meta-ettus/contrib/build_imgs_package.sh e310_sg3 v4.0.0.0`.  For the
debug portion I've added a few lines to `build/conf/local.conf` to add the
packages.  I'm open to suggestions to build the image with debug symbols
and provide additional feedback.

2) I put together a simple flowgraph, UHD source --> frequency xlating fft
--> null sink.  This also segfaults, no guarantees that I got the
parameters correct.

3) Since the issues seem to be with fftw, I decided to try building my own
copy of fftw mostly to get debug symbols and continue troubleshooting.  For
this I used `./configure --enable-debug --enable-shared --enable-threads
--enable-float` and `make CFLAGS="-ggdb"`.  These options are best guesses
right now since I didn't look at the layers to see what parameters it is
using (assuming it is in one of the layers).  Using this build with `export
LD_LIBRARY_PATH=/usr/local/lib/` I do not get a segfault with gr-ais or the
above flowgraph but I also don't get the expected output which makes me
question the parameters I used to build it.  Output wise I get a string of
"D" or "O" to the console.

Thanks

Ben

On Thu, Nov 5, 2020 at 9:22 AM Michael Dickens 
wrote:

> Hi Ben - This issue has been reported to R&D internally. If you wish to
> create a public-facing UHD issue on our Github tracker please go ahead & do
> so, and tag me on it so that we can keep track of it internally. - MLD
>
> On Wed, Nov 4, 2020 at 11:25 PM Ben Magistro via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Is anyone else using meta-ettus-v4.0.0.0 yet?  if so, have you had any
>> issues with libfftw?
>>
>> Using the image on an E310, adding a single OOT module (gr-ais) and
>> trying to run an app distributed with it, the app segfaults.  To further
>> troubleshoot, I added gdb and it comes back with the following.  I have a
>> separate development host that has gnuradio 3.8 setup using pybombs and do
>> not experience this issue there.
>>
>> Thread 1 "python3" received signal SIGSEGV, Segmentation fault.
>> 0xb6947836 in ?? () from /usr/lib/libfftw3f.so.3
>>
>> To compile, I've needed to override PYTHON_EXECUTABLE as it points to a
>> non-existent path in /home/oe-builder in
>> /usr/lib/cmake/gnuradio/GnuradioConfig.cmake.  To run I also needed to
>> define LD_EXPORT_PATH pointing to /usr/local/lib/.
>>
>> Thanks in advance.
>> ___
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] meta-ettus-v4.0.0.0 segfault

2020-11-05 Thread Michael Dickens via USRP-users 
Hi Ben - This issue has been reported to R&D internally. If you wish to
create a public-facing UHD issue on our Github tracker please go ahead & do
so, and tag me on it so that we can keep track of it internally. - MLD

On Wed, Nov 4, 2020 at 11:25 PM Ben Magistro via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Is anyone else using meta-ettus-v4.0.0.0 yet?  if so, have you had any
> issues with libfftw?
>
> Using the image on an E310, adding a single OOT module (gr-ais) and trying
> to run an app distributed with it, the app segfaults.  To further
> troubleshoot, I added gdb and it comes back with the following.  I have a
> separate development host that has gnuradio 3.8 setup using pybombs and do
> not experience this issue there.
>
> Thread 1 "python3" received signal SIGSEGV, Segmentation fault.
> 0xb6947836 in ?? () from /usr/lib/libfftw3f.so.3
>
> To compile, I've needed to override PYTHON_EXECUTABLE as it points to a
> non-existent path in /home/oe-builder in
> /usr/lib/cmake/gnuradio/GnuradioConfig.cmake.  To run I also needed to
> define LD_EXPORT_PATH pointing to /usr/local/lib/.
>
> Thanks in advance.
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] meta-ettus-v4.0.0.0 segfault

2020-11-04 Thread Marcus D Leech via USRP-users 
Do other apps that use FFTs exhibit segfaults. 

Sent from my iPhone

> On Nov 4, 2020, at 11:25 PM, Ben Magistro via USRP-users 
>  wrote:
> 
> 
> Is anyone else using meta-ettus-v4.0.0.0 yet?  if so, have you had any issues 
> with libfftw?
> 
> Using the image on an E310, adding a single OOT module (gr-ais) and trying to 
> run an app distributed with it, the app segfaults.  To further troubleshoot, 
> I added gdb and it comes back with the following.  I have a separate 
> development host that has gnuradio 3.8 setup using pybombs and do not 
> experience this issue there.
> 
> Thread 1 "python3" received signal SIGSEGV, Segmentation fault.
> 0xb6947836 in ?? () from /usr/lib/libfftw3f.so.3
> 
> To compile, I've needed to override PYTHON_EXECUTABLE as it points to a 
> non-existent path in /home/oe-builder in 
> /usr/lib/cmake/gnuradio/GnuradioConfig.cmake.  To run I also needed to define 
> LD_EXPORT_PATH pointing to /usr/local/lib/.
> 
> Thanks in advance.
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] meta-ettus-v4.0.0.0 segfault

2020-11-04 Thread Ben Magistro via USRP-users 
Is anyone else using meta-ettus-v4.0.0.0 yet?  if so, have you had any
issues with libfftw?

Using the image on an E310, adding a single OOT module (gr-ais) and trying
to run an app distributed with it, the app segfaults.  To further
troubleshoot, I added gdb and it comes back with the following.  I have a
separate development host that has gnuradio 3.8 setup using pybombs and do
not experience this issue there.

Thread 1 "python3" received signal SIGSEGV, Segmentation fault.
0xb6947836 in ?? () from /usr/lib/libfftw3f.so.3

To compile, I've needed to override PYTHON_EXECUTABLE as it points to a
non-existent path in /home/oe-builder in
/usr/lib/cmake/gnuradio/GnuradioConfig.cmake.  To run I also needed to
define LD_EXPORT_PATH pointing to /usr/local/lib/.

Thanks in advance.
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com