# Stable on Linux, many crashes on Windows and OS X

**URL:** <https://www.ruby-forum.com/t/stable-on-linux-many-crashes-on-windows-and-os-x/231319>\
**Category:** GNU Radio\
**Created:** [August 3, 2014, 2:35am UTC](https://www.ruby-forum.com/t/stable-on-linux-many-crashes-on-windows-and-os-x/231319 "2014-08-03T02:35:48Z")\
**Posts on this page:** 16\
**Page:** 1

<div class="post-metadata">

**Author:** ![addis\_a](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c4cdca/32.png) [@addis\_a](https://www.ruby-forum.com/u/addis_a)\
**Post date:** [August 3, 2014, 2:35am UTC](https://www.ruby-forum.com/t/stable-on-linux-many-crashes-on-windows-and-os-x/231319/1 "2014-08-03T02:35:48Z")

</div>

Hello,

I want my program to be platform independent (it should work on Linux,  
OS X and Windows).  
Although it runs stable on Linux (Xubuntu 14.04 amd64), on both Windows  
(Win 7 x64) and OS X (10.9) it´s crashing after about a minute.  
For OS X I followed the build guide provided (installed using ports,  
then uninstalled and compiled from source).

This is the console output:

* * *

Mac OS; Clang version 5.1 (clang-503.0.38); Boost\_105500;  
UHD\_003.007.001-0-unknown

gr-osmosdr v0.1.1-10-g9cb023b0 (0.1.2git) gnuradio  
3.7.5git-127-g41d08443  
built-in source types: file fcd rtl rtl\_tcp uhd rfspace  
Using device #0 Realtek RTL2838UHIDIR SN: 00000093  
Found Elonics E4000 tuner  
Using Volk machine: avx\_64\_mmx\_orc  
/Users/stefan/.gnuradio/prefs/vmcircbuf\_default\_factory: No such file or  
directory  
vmcircbuf\_createfilemapping: createfilemapping is not available  
gr::vmcircbuf\_sysv\_shm: shmat(1): Too many open files  
gr::vmcircbuf\_sysv\_shm: shmat(1): Too many open files  
gr::vmcircbuf\_sysv\_shm: shmat(1): Too many open files  
gr::vmcircbuf\_sysv\_shm: shmget(1): Invalid argument  
gr::vmcircbuf\_sysv\_shm: shmget(1): Invalid argument  
gr::vmcircbuf\_sysv\_shm: shmget(1): Invalid argument  
gr::vmcircbuf\_mmap\_shm\_open: mmap or shm\_open is not available  
Segmentation fault: 11

----- Other example -----

Mac OS; Clang version 5.1 (clang-503.0.38); Boost\_105500;  
UHD\_003.007.001-0-unknown

gr-osmosdr v0.1.1-10-g9cb023b0 (0.1.2git) gnuradio  
3.7.5git-127-g41d08443  
built-in source types: file fcd rtl rtl\_tcp uhd rfspace  
Using device #0 Realtek RTL2838UHIDIR SN: 00000093  
Found Elonics E4000 tuner  
Using Volk machine: avx\_64\_mmx\_orc  
VOLK: tried to free a non-VOLK pointer  
Segmentation fault: 11

* * *

Sometimes “VOLK: tried to free a non-VOLK pointer” does not result in a  
crash and the program keeps running normally.

For Windows I compiled GNU Radio using Visual Studio 2012 (x64 build).  
It´s the same here: It works fine for about a minute, then it crashes.  
When I start to debug using Visual Studio, it shows me that the crash  
occurred in the free-function (I cannot see the call stack).

Interestingly on Linux it uses the Volk-machine “avx\_64\_mmx”, on Mac OS  
X “avx\_64\_mmx\_orc” (on Windows I don´t know), although it´s the same  
computer. Is there a difference between these two and could  
“avx\_64\_mmx\_orc” be the reason for the crashes? Can I force GNU Radio to  
use another Volk-machine? Any other ideas?

Best regards  
Stefan

---

<div class="post-metadata">

**Author:** ![Stefan\_O](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/a8b319/32.png) [@Stefan\_O](https://www.ruby-forum.com/u/Stefan_O)\
**Post date:** [August 3, 2014, 3:38am UTC](https://www.ruby-forum.com/t/stable-on-linux-many-crashes-on-windows-and-os-x/231319/2 "2014-08-03T03:38:50Z")

</div>

Hi Stefan - Can you put your program somewhere and post a link to it  
(or, if it is an example, tell us which one) – and the command line you  
use – so that others can try it out? We might not have your exact  
hardware (computer, SDR device), but we can try with what we have and  
see if we get similar results. - MLD

ps\> When doing the “compile from source” on OSX, did you do “make test”  
after doing “make install” to verify that all was well? If not, give  
that a try. You still need to install first on OSX because of the way  
testing finds libraries – it’s on my queue to fix, but I have other  
higher priority items right now.

On Aug 2, 2014, at 8:34 PM, Stefan O. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)  
wrote:

> I want my program to be platform independent (it should work on Linux,  
> OS X and Windows).  
> Although it runs stable on Linux (Xubuntu 14.04 amd64), on both Windows  
> (Win 7 x64) and OS X (10.9) its crashing after about a minute.  
> For OS X I followed the build guide provided (installed using ports,  
> then uninstalled and compiled from source).  
> –  
> Michael D., OSX Programmer  
> Ettus R. Technical Support  
> Email: [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)  
> Web: [http://www.ettus.com](http://www.ettus.com)

---

<div class="post-metadata">

**Author:** ![Stefan\_O](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/a8b319/32.png) [@Stefan\_O](https://www.ruby-forum.com/u/Stefan_O)\
**Post date:** [August 3, 2014, 6:01am UTC](https://www.ruby-forum.com/t/stable-on-linux-many-crashes-on-windows-and-os-x/231319/3 "2014-08-03T06:01:40Z")

</div>

Hi Michael,  
thank you very much for your help. I?ve attached the program in it?s  
current state (messy pre-alpha code) to this mail. It?s a GUI  
application (wxWidgets). On my system it compiles with build\_osx (it?s  
just one line and probably won?t work without editing on other systems).  
After program is started: File-\>Open Transmitter Configuration and  
select example.csv, GNURadio is started and in a timer loop frequency  
will be changed for source and Frequency Xlating filter. On Linux I  
tested it for about two hours and no crash.  
Of course there could also be something wrong with my program and on  
Linux it just doesn?t cause any problem.

It uses OsmoSDR source, so other devices should work as well. Note that  
sample rate is currently hardcoded in the source (2,4 MHz).

I did run make test on OS X and it completed with 100% pass.

Best regards  
Stefan

Am 03.08.2014 03:37, schrieb Michael D.:

---

<div class="post-metadata">

**Author:** ![Stefan\_O](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/a8b319/32.png) [@Stefan\_O](https://www.ruby-forum.com/u/Stefan_O)\
**Post date:** [August 4, 2014, 3:17pm UTC](https://www.ruby-forum.com/t/stable-on-linux-many-crashes-on-windows-and-os-x/231319/4 "2014-08-04T15:17:19Z")

</div>

Hi Stefan - OK; well if “make test” worked on OSX for you then the GR  
install is probably good to go. No guarantees. If you uninstall your  
OO-MacPorts GR install and use gnuradio-devel, then you will should get  
the same results (if not better). I’m not sure why you would want an  
OO-MacPorts GR install unless you wanted to change GR itself.

After tweaking “build\_osx” for my setup, everything builds nicely.  
Running “./batmon” I see an empty window and basic menus; nothing else.  
I can leave it running (in gdb) for a long time without it crashing. I  
don’t know what to do with it otherwise. I have an Ettus B210 hooked  
up.

If I select “batmon” → “About” I see the about box, which when I close  
crashes the executable. Looking through the code in main.cpp,  
BatMonFrame::OnAbout calls BatMonFrame::StopReceiver, which in turn  
calls “gr\_tb-\>stop” even though gr\_tb has not been initialized (I set a  
breakpoint where it is set, and the code does not get there before this  
call). Probably best to check gr\_tb before using it, just in case, in  
all the methods that call it. Also, I’m not sure why you would stop  
processing -after- the about box has been closed; maybe beforehand makes  
more sense?

## If you let me know what else to test, I’ll try that too. Otherwise, without actual functionality the basic GUI seems to “work”. - MLD

Michael D., OSX Programmer  
Ettus R. Technical Support  
Email: [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)  
Web: [http://www.ettus.com](http://www.ettus.com)

---

<div class="post-metadata">

**Author:** ![Stefan\_O](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/a8b319/32.png) [@Stefan\_O](https://www.ruby-forum.com/u/Stefan_O)\
**Post date:** [August 5, 2014, 3:22am UTC](https://www.ruby-forum.com/t/stable-on-linux-many-crashes-on-windows-and-os-x/231319/5 "2014-08-05T03:22:14Z")

</div>

Hi Michael,  
thank you very much for testing! The code is in pre-alpha state, and  
that the About box stops GnuRadio was just a quick-and-dirty hack for  
testing. Normally About should not do anything else than showing the  
About Box.

Please try again and open the included example.csv with the program.  
That creates and starts the GnuRadio flowgraph and continuously changes  
frequency of the hardware and the frequency Xlating filter. You should  
see four symbolized batteries, with RF level (and counter since last  
update when there is a signal) written above, frequency and  
name/description below. In case there is no signal they will be dark  
grey, otherwise light grey (and in case the program detects a battery  
signal it can decode they will be green/yellow/red depending on the  
battery state).

_I think I was just able to isolate the problem_:

When I only do set\_center\_freq(frequency\_offset) with one Frequency  
Xlating filter no crashes. You can test that by removing the first or  
second line of the example.csv (so that two frequency never fit within  
the 2,4 MHz bandwidth). The other Xlating filters still exists and are  
active in the flowgraph, but set\_center\_freq is never called on them.  
Program is stable then.

Just by adding this line:

if((freq\_len+1)\<bat\_decoders.size())  
bat\_decoders[freq\_len+1]-\>SetFreqOffset((int)(bat\_blocks[freq\_pos]-\>GetFreq())-center\_freq);

in the for-loop in the very last function (BatMonFrame::OnTimer) will  
make the program instable again.  
This does nothing else than setting the frequency of the next Frequency  
Xlating filter to the same value (if there is one).

I dont see how this can be a bug in my program, I think it has to be a  
bug in GNURadio (as it is not predictable and caused by doing the same  
thing on two different instances of the same object in very short time  
range -\> my guess would be a threading problem). Can you confirm that?

I tested this on two different systems (Quad-Core Haswell and Dual-Core  
Ivy Bridge mobile), same result for both.

Thank you very much,  
Stefan

Am 04.08.2014 15:16, schrieb Michael D.:

---

<div class="post-metadata">

**Author:** ![Stefan\_O](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/a8b319/32.png) [@Stefan\_O](https://www.ruby-forum.com/u/Stefan_O)\
**Post date:** [August 5, 2014, 3:59pm UTC](https://www.ruby-forum.com/t/stable-on-linux-many-crashes-on-windows-and-os-x/231319/6 "2014-08-05T15:59:58Z")

</div>

## Hi Stefan - OK; cool. Loading up that example, it runs for quite a long time as you describe, before crashing. Here’s the backtrace from gdb when it crashes. So, yes, it looks like either freq\_xlating\_fir\_filter has a bug or you’re not using it correctly; I haven’t had time to look into it further yet. I’d recommend you poke around some more in the freq\_xlating\_fir\_filter and make sure your usage is correct. If you get nowhere, ping the list with the specifics of what you’ve tried including a code-snippet. - MLD {{{ Program received signal EXC\_BAD\_ACCESS, Could not access memory. Reason: KERN\_INVALID\_ADDRESS at address: 0x0000000301000009 [Switching to process 75636 thread 0x13603] 0x0000000101dc4c5b in volk\_free () (gdb) bt #0 0x0000000101dc4c5b in volk\_free () #1 0x0000000101208591 in gr::filter::kernel::fir\_filter\_ccc::set\_taps () #2 0x00000001012185bf in gr::filter::freq\_xlating\_fir\_filter\_ccf\_impl::build\_composite\_fir () #3 0x0000000101218764 in gr::filter::freq\_xlating\_fir\_filter\_ccf\_impl::work () #4 0x0000000100e5af79 in gr::sync\_decimator::general\_work () #5 0x0000000100e2db00 in gr::block\_executor::run\_one\_iteration () #6 0x0000000100e6901d in gr::tpb\_thread\_body::tpb\_thread\_body () #7 0x0000000100e584be in gr::tpb\_container::operator() () #8 0x0000000100e582d4 in gr:🧵:thread\_body\_wrappergr::tpb\_container::operator() () #9 0x0000000100df9ae6 in boost::function0::operator() () #10 0x0000000101f8f625 in boost::(anonymous namespace)::thread\_proxy () #11 0x00007fff9940c772 in \_pthread\_start () #12 0x00007fff993f91a1 in thread\_start () }}}

Michael D., OSX Programmer  
Ettus R. Technical Support  
Email: [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)  
Web: [http://www.ettus.com](http://www.ettus.com)

---

<div class="post-metadata">

**Author:** ![Stefan\_O](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/a8b319/32.png) [@Stefan\_O](https://www.ruby-forum.com/u/Stefan_O)\
**Post date:** [August 5, 2014, 9:14pm UTC](https://www.ruby-forum.com/t/stable-on-linux-many-crashes-on-windows-and-os-x/231319/7 "2014-08-05T21:14:46Z")

</div>

Hi Stephan - You’re welcome; glad you found a work-around that fixes the  
issue!

I’ll let others speak to whether Volk is thread-safe.

I can say that the scheduler is the same no matter the OS; but, the  
actual thread scheduling can be worlds different on different OSs. Thus,  
executing on Linux might be stable at the same time as on OSX and Window  
would not be; it can happen.

## Good luck with your GR work! - MLD

Michael D., OSX Programmer  
Ettus R. Technical Support  
Email: [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)  
Web: [http://www.ettus.com](http://www.ettus.com)

---

<div class="post-metadata">

**Author:** ![Stefan\_O](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/a8b319/32.png) [@Stefan\_O](https://www.ruby-forum.com/u/Stefan_O)\
**Post date:** [August 5, 2014, 9:20pm UTC](https://www.ruby-forum.com/t/stable-on-linux-many-crashes-on-windows-and-os-x/231319/8 "2014-08-05T21:20:07Z")

</div>

On Tue, Aug 5, 2014 at 3:02 PM, Stefan O.  
[removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)  
wrote:

> Volk, or is Volk not supposed to be thread-safe?  
> Can you confirm that bug?
> 
> Why it worked on Linux before, I´m not sure, either other code in  
> GnuRadio is used or the scheduler of the OS is somehow different, so  
> that the problem never occurred.
> 
> Thank you very much  
> Stefan

Stefan,

Great, that explains it. On Linux, you’re using posix\_memalign, but on  
the  
other OS’s, you must be falling through on that into the other  
allocation  
engine, which does not have any thread safety but really should be.

I’ve created ticket #710 and will get to it soon.

Tom

---

<div class="post-metadata">

**Author:** ![Stefan\_O](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/a8b319/32.png) [@Stefan\_O](https://www.ruby-forum.com/u/Stefan_O)\
**Post date:** [August 5, 2014, 9:03pm UTC](https://www.ruby-forum.com/t/stable-on-linux-many-crashes-on-windows-and-os-x/231319/9 "2014-08-05T21:03:28Z")

</div>

Hi Michael,

I was able to fix the problem with an extraordinary ugly hack:

I added a global mutex to GnuRadio and protect  
gr::filter::freq\_xlating\_fir\_filter\_ccf\_impl::build\_composite\_fir with  
it, so only one instance can call  
gr::filter::kernel::fir\_filter\_ccc::set\_taps at the time.

Stable now on both OS X and Windows. I think its definitely a bug in  
Volk, or is Volk not supposed to be thread-safe?  
Can you confirm that bug?

Why it worked on Linux before, Im not sure, either other code in  
GnuRadio is used or the scheduler of the OS is somehow different, so  
that the problem never occurred.

Thank you very much  
Stefan

Am 05.08.2014 15:58, schrieb Michael D.:

---

<div class="post-metadata">

**Author:** ![Stefan\_O](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/a8b319/32.png) [@Stefan\_O](https://www.ruby-forum.com/u/Stefan_O)\
**Post date:** [August 5, 2014, 9:55pm UTC](https://www.ruby-forum.com/t/stable-on-linux-many-crashes-on-windows-and-os-x/231319/10 "2014-08-05T21:55:52Z")

</div>

Yes, its OS X 10.9, but I think I compiled with 10.7 compatibility,  
will check what happens when I recompile with the other allocation  
engine removed.

Am 05.08.2014 21:27, schrieb Michael D.:

---

<div class="post-metadata">

**Author:** ![Stefan\_O](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/a8b319/32.png) [@Stefan\_O](https://www.ruby-forum.com/u/Stefan_O)\
**Post date:** [August 6, 2014, 7:20am UTC](https://www.ruby-forum.com/t/stable-on-linux-many-crashes-on-windows-and-os-x/231319/11 "2014-08-06T07:20:34Z")

</div>

Confirmed its the allocator:  
Recompiling with other allocation engine removed did not work.  
Removed my hack and compiled with posix\_memalign: Stable.  
Thank you very much  
Stefan

Am 05.08.2014 21:54, schrieb Stefan O.:

---

<div class="post-metadata">

**Author:** ![Stefan\_O](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/a8b319/32.png) [@Stefan\_O](https://www.ruby-forum.com/u/Stefan_O)\
**Post date:** [August 5, 2014, 9:28pm UTC](https://www.ruby-forum.com/t/stable-on-linux-many-crashes-on-windows-and-os-x/231319/12 "2014-08-05T21:28:27Z")

</div>

On Aug 5, 2014, at 3:17 PM, Tom R. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> Great, that explains it. On Linux, you’re using posix\_memalign, but on the other  
> OS’s, you must be falling through on that into the other allocation engine, which  
> does not have any thread safety but really should be.
> 
> I’ve created ticket #710 and will get to it soon.

## If Stefan is using OSX 10.8 or 10.9 then he actually is using posix\_memalign – Apple added that function into 10.8+, and I’ve confirmed that GR uses it, too. - MLD

Michael D., OSX Programmer  
Ettus R. Technical Support  
Email: [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)  
Web: [http://www.ettus.com](http://www.ettus.com)

---

<div class="post-metadata">

**Author:** ![Stefan\_O](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/a8b319/32.png) [@Stefan\_O](https://www.ruby-forum.com/u/Stefan_O)\
**Post date:** [August 6, 2014, 8:28pm UTC](https://www.ruby-forum.com/t/stable-on-linux-many-crashes-on-windows-and-os-x/231319/13 "2014-08-06T20:28:06Z")

</div>

Hi Stefan - I’m guessing that the issue Tom made yesterday \<  
[http://gnuradio.org/redmine/issues/710](http://gnuradio.org/redmine/issues/710) \> applies, yes? Was the change  
to your (local; not GR) code, to use posix\_memalign instead of some  
other method of memory allocation? I’m guess I’m not all clear on where  
the issue actual was … but, I’m glad you got the bug figured out  
and/or can work around it without a hack. - MLD

On Aug 5, 2014, at 11:19 PM, Stefan O. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)  
wrote:

> Confirmed its the allocator:  
> Recompiling with other allocation engine removed did not work.  
> Removed my hack and compiled with posix\_memalign: Stable.  
> Thank you very much  
> –  
> Michael D., OSX Programmer  
> Ettus R. Technical Support  
> Email: [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)  
> Web: [http://www.ettus.com](http://www.ettus.com)

---

<div class="post-metadata">

**Author:** ![Stefan\_O](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/a8b319/32.png) [@Stefan\_O](https://www.ruby-forum.com/u/Stefan_O)\
**Post date:** [August 7, 2014, 12:51am UTC](https://www.ruby-forum.com/t/stable-on-linux-many-crashes-on-windows-and-os-x/231319/14 "2014-08-07T00:51:06Z")

</div>

Hi Michael,  
yes, I have not modified my program at all:  
I added a #error “Broken allocation engine” to volk\_malloc.c at the  
beginning of the other allocation engine. I tried to recompile, but  
compiler stopped with my error message. As I did not re-run cmake Im  
sure this engine was also used before.  
Next step I removed my mutex-hack from freq\_xlating\_fir\_filter and  
changed the #if for posix\_memalign test in volk\_malloc.c to #if 1, in  
other words posix\_memalign is always used. Compiled without an error and  
runs stable.  
So Im pretty sure bug #710 is the reason.

The only thing Im not sure is: You said you verified that  
posix\_memalign is used by GnuRadio on OS X. I checked my build process,  
I did not add any OS X 10.7 compatibility command, I used exactly the  
cmake line from the guide:  
[http://gnuradio.org/redmine/projects/gnuradio/wiki/MacInstall](http://gnuradio.org/redmine/projects/gnuradio/wiki/MacInstall) and  
posix\_memalign was not used  
I think either the #if-clause in volk\_malloc.c needs an addition for OS  
X \>= 10.8. or cmake-file needs to be modified.

Best regards  
Stefan

Am 06.08.2014 20:26, schrieb Michael D.:

---

<div class="post-metadata">

**Author:** ![Stefan\_O](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/a8b319/32.png) [@Stefan\_O](https://www.ruby-forum.com/u/Stefan_O)\
**Post date:** [August 7, 2014, 3:53pm UTC](https://www.ruby-forum.com/t/stable-on-linux-many-crashes-on-windows-and-os-x/231319/15 "2014-08-07T15:53:10Z")

</div>

On Aug 6, 2014, at 7:08 PM, Michael D. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)  
wrote:

> I will look into the volk\_malloc you mention.

## I just issued GR pull request 256 “volk: add check for posix\_memalign” \< [volk: add check for posix\_memalign ... by michaelld · Pull Request #256 · gnuradio/gnuradio · GitHub](https://github.com/gnuradio/gnuradio/pull/256) \> that fixes the use of “posix\_memalign” by checking for it in CMake and then using it if found in volk\_malloc.c – and, thus, is OS agnostic. This will fix things for OSX 10.8+, maybe 10.7 too (haven’t checked). But, the issue still remains for OSX 10.6- … which is what GR bug 710 is about \< [http://gnuradio.org/redmine/issues/710](http://gnuradio.org/redmine/issues/710) \>. I’ll leave that to Tom unless he wants me to fix it. - MLD

Michael D., OSX Programmer  
Ettus R. Technical Support  
Email: [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)  
Web: [http://www.ettus.com](http://www.ettus.com)

---

<div class="post-metadata">

**Author:** ![Stefan\_O](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/a8b319/32.png) [@Stefan\_O](https://www.ruby-forum.com/u/Stefan_O)\
**Post date:** [August 7, 2014, 1:10am UTC](https://www.ruby-forum.com/t/stable-on-linux-many-crashes-on-windows-and-os-x/231319/16 "2014-08-07T01:10:08Z")

</div>

On Aug 6, 2014, at 6:50 PM, Stefan O. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)  
wrote:

> yes, I have not modified my program at all:  
> I added a #error “Broken allocation engine” to volk\_malloc.c at the  
> beginning of the other allocation engine. I tried to recompile, but  
> compiler stopped with my error message. As I did not re-run cmake Im  
> sure this engine was also used before.  
> Next step I removed my mutex-hack from freq\_xlating\_fir\_filter and  
> changed the #if for posix\_memalign test in volk\_malloc.c to #if 1, in  
> other words posix\_memalign is always used. Compiled without an error and  
> runs stable.  
> So Im pretty sure bug #710 is the reason.

Very good. Thanks for that thorough testing.

> The only thing Im not sure is: You said you verified that  
> posix\_memalign is used by GnuRadio on OS X. I checked my build process,  
> I did not add any OS X 10.7 compatibility command, I used exactly the  
> cmake line from the guide:  
> [http://gnuradio.org/redmine/projects/gnuradio/wiki/MacInstall](http://gnuradio.org/redmine/projects/gnuradio/wiki/MacInstall) and  
> posix\_memalign was not used  
> I think either the #if-clause in volk\_malloc.c needs an addition for OS  
> X \>= 10.8. or cmake-file needs to be modified.

Ah; different beast. I was talking about the “posix\_memalign” used by  
gnuradio-runtime. GR provides a coarse emulation of this function if  
not provided by the OS. You can verify whether the GR install uses this  
function or not on OSX via “nm -a  
/opt/local/lib/libgnuradio-runtime.dylib | grep memalign” and it should  
return nothing for OSs that provided the function; it should return  
“posix\_memalign” with some other stuff for OSs that do not provide the  
function.

I will look into the volk\_malloc you mention. Volk is designed to be  
separable from GNU Radio, and so it provides it’s own OS-interface  
different from GR’s. Thanks for the pointer! - MLD