segfault commit 16723

[Paul Lambert <paul at planar.id.au>]

I get a segfault with latest SVN on my frontend when playing any audio (mythmusic or recordings). It appears to be related to commit 16723 - when I compile 16722 it works fine, 16723 breaks.

I followed instructions to compile and run gdb, and have attached the stack trace. I can see some things that look suspicious to me, but it appears that too many years in management have sapped my debugging skills. It looks like a segfault in the qt3 library, but amongst my recompiles I've also seen the segfault in mythconfiggroups.cpp without calling through to qt3.

I'm on version 3.3.8b-4 of qt3, and a debian system if that helps, but like I say, I don't believe that to be the problem given that changing the myth code version can make it go away.

I'm happy to extract additional information from gdb or about my system (although working a lot of hours at the moment, so no guarantee of fast turnaround on doing that - it depends on when I notice the request).

Given that it happens on my frontend and not my backend server, I guess the machine may be relevant. My backend is quad core intel, nvidia display driver. Otherwise pretty much same software load as frontend. Frontend is shuttle with celeron M and intel i810 (actually 915 I think, but uses the i810 driver).

[Nigel]

Paul, I had a very similar fault, and had to purge my source tree after the patch [16723]. make clean or distclean

[Paul Lambert <paul at planar.id.au>]

I did a make distclean every time I recompiled through this process - I'm pretty sure that wasn't the issue, although I agree a segfault always looks suspicious.

I am using ccache, but the developer is pretty clear that it wouldn't impact in this scenario.

Is there any other method to clear the source tree that would make a diagnosis? I also checked for any other copies of libmyth.so or libqt-mt on my system, on the offchance that was the issue. The only ones were the ones I had just compiled.

I could do a full new checkout into a new directory, and build from that. I presume that would prove one way or another?

[Roo <roo.watt@…>]

Replying to Paul Lambert <paul at planar.id.au>:

Is there any other method to clear the source tree that would make a diagnosis?

Have a look at the svn-clean script from ​http://packages.debian.org/etch/subversion-tools

[Paul Lambert <paul at planar.id.au>]

Tried again with a full new directory and new checkout. Again, segfault with 16723. It must be using the right libmyth.so, as otherwise the debug symbols wouldn't be there, so I'm also ruling out an old version of libmyth hanging around.

[danielk]

There is a name conflict between AudioSettings? in globalsettings and the public AudioSettings?. Which one is used depends on compiler quirks. I'll commit a fix shortly.

[danielk]

(In [16739]) Fixes #5011. Fixes a class name aliasing bug that was causing segfaults with code generated by some gcc versions.

[Paul Lambert <paul at planar.id.au>]

Excellent work, and very responsive!! I'll retest this evening (my time). Thanks

[Paul Lambert <paul at planar.id.au>]

Yup, fixes the problem for me. Great work.