mythfrontend crashes with SIGSEGV in MythGenericTree::getRouteByString()

[Will Marler <will.marler@…>]

I tried to re-open bug 7098 but I didn't have the permission.

To reproduce the error, put any video without meta-data into the myth-videos dir. Go to "Watch Videos" and hit "m" > "Scan for Changes" so it shows up in the list, and you can edit the meta-data. Then hit "i" > "Metadata Options" > "Edit Metadata" and change the title of the video to something the metadata grabber script will be able to retrieve data for. Then select "done". Browse back to the file, hit "i" > "Metadata Options" again, this time select "Download Metadata". Then "m" and "Scan for Changes". This is when mythfrontend crashes.

I noticed 2 things with this crash. 1: It occurred the first time after I had populated metadata using the mythweb plugin. (I had edited metadata using the web interface, not the mythfrontend interface). 2: it seems to happen if the title of the show needs to be changed. If the title does not need to be changed, but only subtitle or season/episode is changed, or only the images are downloaded, then "Scan for Changes" doesn't cause a crash.

Please email me if you need any further information. This is my first time capturing a gdb.txt and submitting a bug; I'm sure I made mistakes. I'm classifying the Priority as "major" because of the constant need to restart mythfrontend when editing metadata, but I won't object if you say "but you can just scan for changes after you've made a lot" and change the priority back to minor. Thanks for the great work!

[robertm]

Bumping this down to a lower priority. I am looking at it, it's just not max priority since it requires a very specific set of events, and only in tree view, and only in themes that use the breadcrumbs widget.

[Will Marler <will.marler@…>]

Hmm, I'm not sure I agree that "changing the name of the title" qualifies as "very specific set of events." What else contributes, if not the name of the title? (Do the characters in the title contribute? Ie, ',?', '(' etc?)

What is this "tree view" that you mention? If there is an easy fix by using a different view, I'd certainly check it out, but i'm not sure where this is configured. I *think* I'm using a default screen... so while the bug may require a specific setup to reproduce, it's also the setup that everyone gets OOTB.

[Will Marler <will.marler@…>]

I did not "preview" my above post, and the "characters in the title" that I was asking about got edited out. I was referring to open square bracket and close square bracket.

[robertm]

Will, The above is an administrative/organizational decision, not a dismissal of the ticket. It has to do with how we decide when to cut a release candidate/etc. The issue is clear and will get fixed. If you have questions the best place to take them is the mailing list, not the ticket. See the MythVideo? documentation in the wiki for a better understanding of the available views. The need to be in a specific view, with a specific them that uses a specific themed widget, along with the need to edit metadata and then scan for changes is quite specific. It makes it a bug that not everyone will experience.

It'll get fixed.

[robertm]

Issue no longer seems to appear in trunk. I believe this is because of some metadata parsing changes I made after .22 was released. If you are able to reproduce when .23 comes out, ping me on list and I will re-open.

For reference my test titles were "Star Wars" and "Star Trek 2009."

[markk]

This is still an issue with trunk when using the Mythbuntu, Graphite and Terra themes. Arclight crashes before getting to the scan. Not tested with any other themes.

For me, to re-create: Enter the Video List view, ask for rescan and it crashes literally every other scan (it's entirely consistent).

The one oddity I've noticed is that the scan refresh is consistently reporting a hash 'conflict' on two files (ie. the hash is already in the database) and it ping pongs the filename between 2 entirely different files for the same entry.

I'll attach logs later (which will hopefully make that lost comment a little clearer).

[robertm]

This probably should have occurred to me long, long ago, but Mark, can you test this patch?

[robertm]

Moreover, if this doesn't work (and I half think it won't), I need a backtrace with debug symbols since it's dying in getRouteByString and I can't see what part of the data being passed to it is invalid.

[robertm]

(In [25036]) Add more null checking to MythVideo? main dialog, and set the m_currentNode value to NULL when reloading the tree following a scan. My theory is that while the tree was being invalidated, failing to set the m_currentNode to NULL is what was causing the crashes as the pointer was non-null but non-valid after the invalidation of the tree. (I hope) Fixes #7689. If it doesn't we can re-open for another go-round.