MythMusic crashes when visualizers are changed repeatedly

[otto at kolsi dot fi]

When visualizers are changed repeatedly, MythMusic crashes. This happens e.g. if 'change visualizer' button is kept pressed, songs are changed quickly so that visualizers also get changed or same song is repeatedly started from the beginning (again, visualizers are changing fast).

Attached is a backtrace. This was confirmed and briefly discussed in IRC without immediate solution.

[skd5aner@…]

Not sure if this is related to #3792 or not, but look there for comments from my on basically the same issue. Basically, regardless of speed of repeating visualization changes, mythfrontend crashes whenever I change to the sixth visualization (regardless to what the visualization actually is).

[paulh]

I don't seem to be able to reproduce this at all. Is the BT the same after each crash? Can you reproduce it on different frontends? I may need your music settings just in case it's specific to a particular combination of settings.

Can't reproduce the problem on #3792 either.

[stuartm]

I was able to reproduce this but as it appears to be timing related I had to slow the system down to do it. I looked at this for a long time in irc but I couldn't see what was wrong, maybe a second pair of eyes will help.

My suspicion was that it had something to do with the Spectrum visualiser not getting to initialise indices with any values in LogScale? before it was destroyed, but I couldn't really explain that. Even if "indices = new Int[0];" it still shouldn't segfault when "delete [] indices" is called.

[otto at kolsi dot fi]

Replying to paulh:

I don't seem to be able to reproduce this at all. Is the BT the same after each crash? Can you reproduce it on different frontends? I may need your music settings just in case it's specific to a particular combination of settings.

Just to clarify this a bit: the backtrace is from a colleague of mine, I cannot reproduce this either with my frontends. So probably timing / environment issue. But since stuartm was able to reproduce it I created the ticket.

If needed I can ask for more backtraces and/or the music settings.

[skd5aner@…]

OK... Well, I finally fixed another problem with mythmusic, so now I can help report some info here. After starting a track, I hit "4" to bring up the full screen visualization. Then, I hit "6". After my 8'th or 9'th (can't remember) visualization switch, I get a segfault. Here is what the last few lines of my mythfrontend -v all log says:

2007-08-22 13:10:50.836 AO: Broadcasting free space avail
2007-08-22 13:10:50.836 WriteAudio: Preparing 6144 bytes (1536 frames)
2007-08-22 13:10:50.836 AO: audio waiting for space on soundcard: have 588 need 6144
2007-08-22 13:10:50.846 AO: _AddSamples bytes=2048, used=759809, free=8191, timecode=-1
2007-08-22 13:10:50.846 AO: _AddSamples bytes=2048, used=761857, free=6143, timecode=-1
2007-08-22 13:10:50.846 AO: _AddSamples bytes=2048, used=763905, free=4095, timecode=-1
2007-08-22 13:10:50.846 AO: AddSamples FAILED bytes=2048, used=765953, free=2047, timecode=-1
2007-08-22 13:10:50.856 AO: audio waiting for space on soundcard: have 4084 need 6144
2007-08-22 13:10:50.876 AO: Broadcasting free space avail
2007-08-22 13:10:50.876 WriteAudio: Preparing 6144 bytes (1536 frames)
2007-08-22 13:10:50.876 AO: audio waiting for space on soundcard: have 1528 need 6144
2007-08-22 13:10:50.876 AO: _AddSamples bytes=2048, used=759809, free=8191, timecode=-1
2007-08-22 13:10:50.876 AO: _AddSamples bytes=2048, used=761857, free=6143, timecode=-1
2007-08-22 13:10:50.876 AO: _AddSamples bytes=2048, used=763905, free=4095, timecode=-1
2007-08-22 13:10:50.876 AO: AddSamples FAILED bytes=2048, used=765953, free=2047, timecode=-1
2007-08-22 13:10:50.888 DPMS Reactivated.
2007-08-22 13:10:50.889 DPMS Deactivated
2007-08-22 13:10:50.895 AO: AddSamples FAILED bytes=2048, used=765953, free=2047, timecode=-1
2007-08-22 13:10:50.900 AO: AddSamples FAILED bytes=2048, used=765953, free=2047, timecode=-1
/usr/local/bin/mythfrontend: symbol lookup error: /usr/lib/libvisual-0.4/actor/actor_nastyfft.so: undefined symbol: visual_mem_malloc0

And I'm attaching my gdb.txt log as well.

[otto at kolsi dot fi]

Replying to skd5aner@gmail.com:

After starting a track, I hit "4" to bring up the full screen visualization. Then, I hit "6". After my 8'th or 9'th (can't remember) visualization switch, I get a segfault. Here is what the last few lines of my mythfrontend -v all log says: ... /usr/local/bin/mythfrontend: symbol lookup error: /usr/lib/libvisual-0.4/actor/actor_nastyfft.so: undefined symbol: visual_mem_malloc0

I think we might be seeing here still two different crashes. I myself cannot use all the libvisual visualizers since some of those crash frontend (not always but frequently enough). I think/guess your log shows that your crash is with libvisual visualizers.

But the original bactrace in this ticket was happening without any libvisual visualizers. So this is more of a Myth issue.

Anyone know if there's point compiling libvisual visualizers and getting proper bactraces? Is there a place where these problems could be reported and hopefully fixed? Some libvisual websites don't seem so promising..

[myth@…]

In MythMusic-crash.txt, line 620 ;

#4  0x00002aaab2784917 in MainVisual::setVisual (this=0x127ed70,

the this address looks all wrong compared to other this pointers and such. Only the allmusic is at 0x12xxxx, but I might be completely on the wrong track here.

The playbackbox seems valid, same this pointer in line 623 as the dialog object in line 643.

Could it be that cycle visualisations causes the MainVisual::setVisual to get called from one thread while another thread causes MainVisual::hideEvent to get called ? That could possibly lead to setVisual deleting vis after hideEvent deletes vis.

[paulh]

Replying to myth@eskil.org:

Could it be that cycle visualisations causes the MainVisual::setVisual to get called from one thread while another thread causes MainVisual::hideEvent to get called ? That could possibly lead to setVisual deleting vis after hideEvent deletes vis.

I thought you might be on to something there but nope hideEvent() is only called once when playbackbox is closed. I wish I could actually reproduce this it would make it a lot easier to figure out what is happening.

[anonymous]

Replying to paulh:

I thought you might be on to something there but nope hideEvent() is only called once when playbackbox is closed. I wish I could actually reproduce this it would make it a lot easier to figure out what is happening.

You're right. I added printfs all over and didn't see anywhere where MainVisual? got called into from another thread at all. I also ran it through valgrind and didn't see anything noteworthy there.

And I guess if maxrange was negative when new int[maxrange] is called, there would have been an exception.

What about ;

mainvisual.cpp(LogScale::setMax)
    for (i = 1; i < (int) domain; i++) {
        scaled = (int) floor(0.5 + (alpha * log((double(i) + alpha) / alpha)));
        if (indices[scaled - 1] < i)
            indices[scaled - 1] = i;
    }

I don't get all the math that's going on prior to that (aka lazy, didn't try more than once), but it depends on the input, so if scaled ends up being 0, then indices[scaled-1] would read the allocators bookkeeping data, which could easily be < (int)i. Now writing i into the bookkeeping data could easily cause free to die.

I tried setting scale to zero, and I got ;

*** glibc detected *** /opt/mythtv/bin/mythfrontend: munmap_chunk(): invalid pointer: 0x0977afc0 ***
======= Backtrace: =========
/lib/tls/i686/cmov/libc.so.6(cfree+0x1bb)[0xb5a6c92b]
/usr/lib/libstdc++.so.6(_ZdlPv+0x21)[0xb5c31d81]
/usr/lib/libstdc++.so.6(_ZdaPv+0x1d)[0xb5c31ddd]
/opt/mythtv/lib/mythtv/plugins/libmythmusic.so(_ZN8LogScaleD1Ev+0x341)[0xb25ef05f]
/opt/mythtv/lib/mythtv/plugins/libmythmusic.so(_ZN8SpectrumD2Ev+0xb1)[0xb263a92d]
/opt/mythtv/lib/mythtv/plugins/libmythmusic.so(_ZN7SquaresD0Ev+0x2b)[0xb263aa37]
/opt/mythtv/lib/mythtv/plugins/libmythmusic.so(_ZN10MainVisual9setVisualERK7QStr

looks pretty similar.

[myth@…]

not anonymous, just me again.

[myth@…]

possible fix for crash

[myth@…]

I've attached a possible fix - but someone who can reproduce the crash (I can't) should try it. I'm guessing it's only reproducible if you're using Gears and Spectrum visualisers.

[otto at kolsi dot fi]

After opening this ticket I've upgraded hardware and rebuilt a frontend upgrading from FC5 -> FC8. With the new system it seems that none of the Myth visualizers crash, only some of the libvisual visualizers. All the others than those mentioned below seem to work fine even when 'tortured' with repeated changes etc.

Some libvisual visualizers output errors before/during crash, e.g.:

nastyfft:

/usr/local/bin/mythfrontend: symbol lookup error: /usr/lib/libvisual-0.4/actor/actor_nastyfft.so: undefined symbol: visual_mem_malloc0

gdkpixbuff:

(process:5946): GdkPixbuf-CRITICAL **: gdk_pixbuf_scale_simple: assertion `src != NULL' failed
libvisual CRITICAL: mythmusic: update_scaled_pixbuf(): assertion `priv->scaled != NULL' failed

gforce:

libvisual CRITICAL: mythmusic: mfl_DestroyFont(): assertion `f != NULL' failed

jess crashes and doesn't output anything. Backtrace of one of the crashes is attached.

I think the original problem for me has either been solved by some changeset or the system upgrade solved it. Can someone confirm from the latest backtrace that the crash does not occur within MythMusic? And finally, if libvisual component crashes, there is no point taking backtraces since nothing can be done within MythMusic?

[stuartm]

(In [18431]) Fix potential out of bounds error which may have been triggering the segfault with mythmusic's visualisers. Closes #3836. This doesn't fix segfaults caused by libvisual visualisers which should probably be forwarded upstream, at the very least those should be handled in a seperate ticket.

[stuartm]

(In [18442]) Backport [18431] to -fixes. Fix potential out of bounds error with mythmusic's visualisers. Refs #3836.