Re: [Discuss-gnuradio] gr-audio-oss segfaults

[Eric Blossom]

On Fri, Apr 07, 2006 at 11:52:47AM +0930, Berndt Josef Wulf wrote:
> On Friday 07 April 2006 11:35, Eric Blossom wrote:
> > On Fri, Apr 07, 2006 at 07:50:53AM +0930, Berndt Josef Wulf wrote:
> > > G'day,
> > >
> > > gr-audio-oss segfaults when built using the gr-audio-oss-0.8.tar.gz
> > > tarball. The reason for this is that the tarball includes audio_oss.cc
> > > which normally is created by swig. Consequently, the interfaces created
> > > in this file may not be correct for the  every target system. I guess
> > > this was overlooked during the  creation of the tarball.
> > >
> > > It would be nice if we can create a new tarball e.g
> > > gr-audio-oss-0.8.1.tar.gz that excludes this file. I believe that package
> > > maintainers would appreciate this.
> > >
> > > cheerio Berndt
> >
> > Hi Berndt,
> >
> > After taking a look at this, I think the problem is in the
> > gnuradio-core build process.  All the tarballs that I checked
> > designate the swig generated output files as BUILT_SOURCES, and all
> > contain the output of running swig on the machine I built the tarballs
> > on.
> >
> > That part is right.
> >
> > The part that's wrong, is that something in the gnuradio-core build
> > process is triggering a dependency that's having gnuradio-core's swig
> > output be regenerated.  This could lead to a situation where
> > gnuradio-core's stuff is built with one version of swig, while all the
> > others use a different version.  I suspect that some of the machine
> > generated code (particularly the .i and .h files) in general and/or
> > filter isn't labeled BUILT_SOURCES, and thus isn't in the tarball.
> > Building that stuff would then force swig to be run, causing the
> > potential swig version inconsistency.
> 
> Not quite sure what you mean. Currently I have to regenerate this file with 
> swig in order to avoid the segfault.
> 
> The log below shows the part that does go wrong. Note that swig wasn't 
> executed in order to regenerate audio_oss.cc

Note that the compile from the the tarball *does* succeed.  It does
generate some warnings about "defined but unused", but no compile time
errors.

I believe the reason you're seeing the segfault (based on
circumstantial evidence -- I don't even know *where* it's blowing up)
is that the gnuradio-core tarball *does* run swig (which it
shouldn't), while the other tarballs *don't* run swig.  This would
result in gnuradio-core using "your version of swig" and all the other
tarballs using "my version of swig".  As long as they all use the
same version of swig, everything should be OK.  Right now they're not.

Let me be clear: when compiling the tarballs, swig should *not* run 
[at least that was the original intention ;) ] The fact that it is run
when building the gnuradio-core tarball is *incorrect*, and is what I
believe is causing the problem.

So, I think there are two solutions: ensure that either all of them run swig,
or that none of them run swig.

>
> > I'll continue to investigate, but not right now.
> >
> >
> > If someone else wants to help sort this out, please dive in.
> >
> > BTW, this problem isn't new.  It's been in all the tarballs generated
> > over the last couple of years.  I think we're seeing it now because I
> > used swig 1.3.29 on the build machine.  The swig generated code changed
> > for the better between 1.3.27 and 1.3.28.
> 
> This would make sense as the version of swig used here is 1.3.27.

That's good to know.

> I was going to commit an update of the latest gnuradio release into pkgsrc 
> and 
> will have to work around it if no solution comes from here.

I appreciate your efforts.  Maybe you should hold off a few days and
see if a solution materializes.


> BTW: I've since create a package for gr-audio-portaudio which I hope to 
> commit 
> soon.

Good.

How does gr-audio-portaudio sound under NetBSD?
Does it work as well as gr-audio-oss?

FWIW, my impression of gr-audio-portaudio under GNU/Linux is that it's
not ready for prime time.  I'd still choose gr-audio-alsa over
portaudio.  It still needs some work.  Not sure if it's in our code,
the portaudio code, or both.

Eric