Opened 10 years ago

Closed 10 years ago

#7011 closed defect (fixed)

segfault on startup of mythfrontend

Reported by: davidbuzz@… Owned by: Nigel
Priority: major Milestone: 0.22
Component: MythTV - General Version: head
Severity: high Keywords:
Cc: Ticket locked: no

Description (last modified by Nigel)

using the standard mythfrontend.cmd file for debugging my mythfrontend.exe give me this backtrace on startup. version is a newly downloaded 21709 ( ie current head).

Program received signal SIGSEGV, Segmentation fault.
0x09666434 in TriggeredConfigurationGroup::Save (this=0xf12dbb0) at mythconfiggroups.cpp:521
521             configStack->Save();

...

Thread 1 (thread 1628.0x82c):
#0  0x09666434 in TriggeredConfigurationGroup::Save (this=0xf12dbb0) at mythconf
iggroups.cpp:521
        this = (class TriggeredConfigurationGroup * const) 0xf12dbb0
#1  0x0f135bdc in ?? ()
No symbol table info available.
#2  0x0f135be0 in ?? ()
No symbol table info available.
#3  0x0965f5c2 in ConfigurationGroup::Save (this=0x7c90e920) at mythconfiggroups
.cpp:99
        this = (class ConfigurationGroup * const) 0xf10e5e8
#4  0x00000000 in ?? ()
No symbol table info available.
(gdb)

Attachments (1)

gdb.txt (2.1 KB) - added by davidbuzz@… 10 years ago.
same backtrace , but as a file, may be easier to read.

Download all attachments as: .zip

Change History (7)

Changed 10 years ago by davidbuzz@…

Attachment: gdb.txt added

same backtrace , but as a file, may be easier to read.

comment:1 Changed 10 years ago by Nigel

Description: modified (diff)
Status: newassigned

Haven't looked closely at BT or tried to reproduce, but I have seen that happen when mythfrontend is run against an empty database (i.e. mythconverg with no tables)

comment:2 Changed 10 years ago by davidbuzz@…

OK, that would make sense, but isn't it still a bug? Crashing is never good. Perhaps just a nice error message and a clean shutdown would be OK?

comment:3 Changed 10 years ago by Nigel

Component: Ports - WindowsMythTV - General
Description: modified (diff)
Severity: mediumhigh
Summary: segfault on startup of mythfrontend - win32 - backtrace attached.segfault on startup of mythfrontend

With a totally empty database, have reproduced (near enough) on Mac OS X:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000000
0x023bc180 in TriggeredConfigurationGroup::Save ()

and Linux:

2009-09-18 10:54:34.902 Driver error was [2/1146]:
QMYSQL3: Unable to prepare statement
Database error was:
Table 'mythconverg3.settings' doesn't exist

2009-09-18 10:54:34.903 DB Error (SimpleDBStorage::Save() query):
Query was:
SELECT * FROM settings WHERE value = ? AND hostname = ?;
Bindings were:
:WHEREHOSTNAME=macaque.ind.tansu.com.au, :WHEREVALUE=EndOfRecordingExitPrompt
No error type from QSqlError?  Strange...

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1282136336 (LWP 18050)]
0xb66b0f8f in TriggeredConfigurationGroup::Save (this=0x82dd1e0) at mythconfiggroups.cpp:521
521             configStack->Save();
#0  0xb66b0f8f in TriggeredConfigurationGroup::Save (this=0x82dd1e0) at mythconfiggroups.cpp:521
#1  0xb66ab7ec in ConfigurationGroup::Save (this=0x8332a38) at mythconfiggroups.cpp:99
#2  0x080840cd in ConfigurationDialog::Save (this=0xbf87f744) at ../../libs/libmyth/mythconfigdialogs.h:111
#3  0x0807a6a8 in WriteDefaults () at main.cpp:640
#4  0x0807ecc5 in main (argc=1, argv=0xbf87fcb4) at main.cpp:1409

Interestingly, other programs that are supposedly not allowed to upgrade schema (like mythav and mythfilldatabase) do not exhibit the error, but they are also eventually populating the database, so there is also an error in the schema wizard logic?

comment:4 Changed 10 years ago by Nigel

Status: assignedstarted

OK. It seems like I caused this in [19409]. Moving the call to WriteDefaults() to after !UpgradeTVDatabaseSchema() prevents the crash, but gives; 1) an unresponsive GUI on Mac OS X, 2) No GUI on Linux (can't find themes), and 3) a working (default) GUI on Windows.
I will commit that now (to fix the crash), and maybe later add an empty database check (in MythContext's database bootstrapping)

comment:5 Changed 10 years ago by Nigel

(In [21929]) Prevent crash when starting with a completely empty database. Refs #7011

comment:6 Changed 10 years ago by Nigel

Resolution: fixed
Status: startedclosed

I think the segfault is fixed, so will close this and create a fresh ticket for "empty database" problems.

Note: See TracTickets for help on using tickets.