MythTV 0.25 crashes (libQtCore segfault)

[amlopezalonso@…]

Since upgrading to 0.25.0~master.20110809.8f37c6e, MythTV crashes (both backend/frontend) with the following dmesg output:

[ 8275.204453] mythfrontend.re[3542]: segfault at 0 ip 00007f2b717a8bdc sp 00007fff4819c160 error 4 in libQtCore.so.4.7.2[7f2b71739000+283000]

[ 8562.687249] mythtv-setup.re[3620]: segfault at 0 ip 00007ff866348bdc sp 00007fff50cefb20 error 4 in libQtCore.so.4.7.2[7ff8662d9000+283000]

[ 8562.767544] mythbackend[3630]: segfault at 0 ip 00007f8f3b733bdc sp 00007fffc08bba30 error 4 in libQtCore.so.4.7.2[7f8f3b6c4000+283000]

[ 8562.799909] mythbackend[3635]: segfault at 0 ip 00007f2500d96bdc sp 00007fffaa54b870 error 4 in libQtCore.so.4.7.2[7f2500d27000+283000]

[ 8562.826665] mythbackend[3640]: segfault at 0 ip 00007f7cb04f0bdc sp 00007fffadfaae80 error 4 in libQtCore.so.4.7.2[7f7cb0481000+283000]

[ 8568.250748] mythfilldatabas[3645]: segfault at 0 ip 00007f075097ebdc sp 00007fff49c36f50 error 4 in libQtCore.so.4.7.2[7f075090f000+283000]

Regards, Antonio

[wagnerrp]

We can't do anything without a backtrace.

[amlopezalons]

mythfrontend.real backtrace

[amlopezalonso@…]

OK there you are (for mythfrontend.real).

Regards, Antonio

[paulh]

You need to update again, that bug has already been fixed

[andreaz@…]

The remote frontend on one of my machines is still crashing right after it draws the main menu screen: mythfrontend[9987]: segfault at 60 ip b2ac0b6f sp a0908a20 error 4 in libQtCore.so.4.6.3[b2a60000+274000]

On my combined FE/BE the frontend is working fine.

[danielk]

Andreaz, we will need a backtrace of the crash with [f4ba7827e1] or later to re-open.

[andreaz@…]

gdb textfile

[andreaz@…]

Attached a gdb textfile. Hope its okay like it is. I've done it the first time as described in the manual on mythtv.org in 22.2. If you need more, please let me know. Thanks in advance!

[danielk]

Andreas,

The backend backtrace doesn't have symbols loaded. If your installing from a package there is usually a matching -dbg package containing the debugging symbols. I need these to figure out what's going on. I also need the backend and frontend log's for this run.

[andreaz@…]

Hey danielk,

this is a compile from source. I thought --compile-type=debug would make the symbols visible? Maybe lead my hand in the right direction? Im really not familar in providing good backtraces. If you can tell me what to do, i will provide a better backtrace including the logs for the frontend and backend (even the backend is on a different machine).

Regards and thx alot, Andreas

[raymondboettcher@…]

Andreaz,

I just had the same issue the other day documented on ticket #9670, commit e433387. Grab the master again, it works now! But stay away from the last few days, many issues with QT and SQL Database problems that they were re-working that caused many things to break temporally. I've been following the commit history daily for the last week. If it still breaks, I'll help you backtrace. Let them program, they do good work. :)

[raymondboettcher@…]

ohh and btw, found this: ​http://www.mythtv.org/wiki/Debugging and I don't think I could have explained it better myself. :)

[andreaz@…]

Okay, this moment i grab the master and build it again. I'll see if this is gone away. Strange thing is, that it worked perfectly on my combined FE/BE, but not on my remote FE. And sure. All that are responsible for mythtv do a great, great work. Thats so true.

[raymondboettcher@…]

Remote FE running same linux os version / QT Version? Seems really strange that a remote FE would have problems and not a local FE. In my instance, both Mythbackend and Mythfrontend wouldn't start at all. gdb mentioned a call to QT being responsible. The next day I downloaded another commit and that one worked but the DB wouldn't install due to their reworking of dedicated connections to the SQL Server. Sometimes, you end up downloading a commit and their actually right in the middle of something and you end up finding a small list of commits that fail to work at all.

[Github]

Refs #9981. Release recording path cache lock while we're doing the ProgramInfo::GetPlaybackURL() lookup. This call can take a very long time if there is a filesystem problem we don't want to spread that problem to other worker threads.

Branch: master Changeset: 0b17b4ce9c08b3bc821fc28575f7b9e0db03cb0d

[beirdo]

Is this confirmed to be fixed, or is a more up-to-date backtrace still required?

[amlopezalonso@…]

I'm not getting the original crash anymore. However, exiting a FE ends sometimes in a crash but maybe due to some other reason.

[beirdo]

OK, let's close this one, and could you report the new issue in a new ticket (including a backtrace of what crashes, please). Thanks for getting back to us.