Opened 10 years ago
Closed 10 years ago
#7011 closed defect (fixed)
segfault on startup of mythfrontend
Reported by: | Owned by: | Nigel | |
---|---|---|---|
Priority: | major | Milestone: | 0.22 |
Component: | MythTV - General | Version: | head |
Severity: | high | Keywords: | |
Cc: | Ticket locked: | no |
Description (last modified by )
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)
Change History (7)
comment:1 Changed 10 years ago by
Description: | modified (diff) |
---|---|
Status: | new → assigned |
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
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
Component: | Ports - Windows → MythTV - General |
---|---|
Description: | modified (diff) |
Severity: | medium → high |
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
Status: | assigned → started |
---|
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
comment:6 Changed 10 years ago by
Resolution: | → fixed |
---|---|
Status: | started → closed |
I think the segfault is fixed, so will close this and create a fresh ticket for "empty database" problems.
same backtrace , but as a file, may be easier to read.