Opened 13 years ago

Closed 11 years ago

#9819 closed Bug Report - Crash (Fixed)

Windows frontend ASSERT failure in QCoreApplication::sendEvent

Reported by: seven@… Owned by: JYA
Priority: minor Milestone: 0.27
Component: MythTV - General Version: 0.24-fixes
Severity: medium Keywords: Windows
Cc: Ticket locked: no

Description

I've running the Windows Binary from http://members.iinet.net.au/~davco/

0.24-fixes 188-g8ba07a0 and also in 0.24.1 1-g347cd24

I have tried removing the prompt to delete at end of recoring setting and also the mark as watched at end of recording setting just to test but it also happens when exiting anywhere in the recording not only at the end.

It doesn't happen every single time but probably 90% of the time

ASSERT failure in QCoreApplication::sendEvent: "Cannot send events to objects ow ned by a different thread. Current thread fa072d0. Receiver (of type 'Preview Generator') was created in thread 314ed040", file kernel\qcoreapplication.cpp, l ine 348

if you need me to provide any further information but both machines are running Windows 7 but one is 32bit and the other 64bit.

Attachments (4)

mythtv-9819-0.24-fixes-use_dispatch_for_sendPlaybackStart_and_End.patch (655 bytes) - added by sphery 13 years ago.
Completely untested (not even compile-tested) patch for 0.24-fixes to potentially fix the issue. (Same changes would be required in master, but files have been moved.)
gdb.txt (3.0 KB) - added by seven@… 13 years ago.
gdb.txt debug build
mythtv-9819-PauseAllPlugins_on_playback_start_and_resume_on_end.patch (8.6 KB) - added by sphery 12 years ago.
Not-completely-updated patch referenced in comment:3
mythplugins-9819-mythmusic_pause_resume_on_playback_start_and_end.patch (1.1 KB) - added by sphery 12 years ago.
mythplugins portion of not-completely-updated version of patch referenced in comment:3

Download all attachments as: .zip

Change History (21)

comment:1 Changed 13 years ago by danielk

Milestone: unknown0.25
Priority: majorminor
Status: newinfoneeded_new

If you could provide a backtrace we should be able to fix this fairly quickly. Unfortunately I don't think we have instructions on how to do that from a core under Windows, but you may be able to reproduce this running MythTV under gdb in which case the instructions linked to from the TicketHowTo should work.

comment:2 Changed 13 years ago by sphery

Looks like this is another case similar to the one we saw in #5172 (fixed in 99f0e069 ), but via the dispatchNow() used in sendPlaybackEnd() (and there's another in sendPlaybackStart() that may need changing, too) around https://github.com/MythTV/mythtv/blob/master/mythtv/libs/libmythbase/util.cpp#L1020 .

Changed 13 years ago by sphery

Completely untested (not even compile-tested) patch for 0.24-fixes to potentially fix the issue. (Same changes would be required in master, but files have been moved.)

comment:3 Changed 13 years ago by paulh

Completely untested (not even compile-tested) patch for 0.24-fixes to potentially fix the issue. (Same changes would be required in master, but files have been moved.)

I don't think this patch will work because you can't guarantee that the music player will receive the event and release the audio output before the video player starts playing that's why dispatchNow() is being used in those places.

There is a patch on a ticket somewhere from me that removes the depreciated dispatchNow() stuff completely but it was rejected for some reason can't exactly remember why. I think opinion was divided on how best to remove it and in the end it was easier to just leave it the way it is since it's not really broken at least not in linux.

comment:4 Changed 13 years ago by seven@…

Not sure the build would have any debugging compiled in so I've asked the packager to provide a debug build but here is the inital gdb logs theres also a 18MB log file which I'll upload somewhere, I'm unsure where the coredump would have been saved though unless its in the 18MB logfile?

C:\Program Files (x86)\mythtv\bin>c:\mingw\bin\gdb.exe mythfrontend.exe -x gdbco mmands Function "qFatal" not defined. Breakpoint 1 (qFatal) pending. [New Thread 4560.0x12e4] [New Thread 4560.0xd90] [New Thread 4560.0x1de4] [New Thread 4560.0x1420] [New Thread 4560.0x1938] [New Thread 4560.0xb14] [New Thread 4560.0x15a8] [New Thread 4560.0xf10] [New Thread 4560.0x2b0] [New Thread 4560.0xefc] [New Thread 4560.0x1d10] [New Thread 4560.0x1818] [New Thread 4560.0x1664] [New Thread 4560.0x1dc] [New Thread 4560.0x1490] [New Thread 4560.0xb84] [New Thread 4560.0x167c] [New Thread 4560.0x1df0] [New Thread 4560.0x1ad4] [New Thread 4560.0x1e50] [New Thread 4560.0x44c] [New Thread 4560.0x1b00] [New Thread 4560.0x140c] [New Thread 4560.0x16dc] [New Thread 4560.0x1648] [New Thread 4560.0x1738] [New Thread 4560.0x1e80] [New Thread 4560.0x1878] [New Thread 4560.0x17f8] [New Thread 4560.0x1c90] [New Thread 4560.0x1ab4] [New Thread 4560.0x1ce8] [New Thread 4560.0x3b0] [New Thread 4560.0x180c] [New Thread 4560.0x84c] [New Thread 4560.0x260] [New Thread 4560.0x1414] [New Thread 4560.0xb6c] [New Thread 4560.0x1644] [New Thread 4560.0x1860] [New Thread 4560.0x1f0c] [New Thread 4560.0x1eb0] [New Thread 4560.0x176c] [New Thread 4560.0x1144] [New Thread 4560.0x1004] [New Thread 4560.0x12fc] [New Thread 4560.0x1d34] [New Thread 4560.0x1e00] [New Thread 4560.0x1704] [New Thread 4560.0x1a10] [New Thread 4560.0x12c8] [New Thread 4560.0x1a84] [New Thread 4560.0x1884] [New Thread 4560.0x470] [New Thread 4560.0x15ac] [New Thread 4560.0x1ee8] [New Thread 4560.0x1894] [New Thread 4560.0x1e4c] [New Thread 4560.0x133c] [New Thread 4560.0x980] [New Thread 4560.0x137c] [New Thread 4560.0xc84] [New Thread 4560.0xe9c] [New Thread 4560.0x1620] [New Thread 4560.0x1460] [New Thread 4560.0x328] [New Thread 4560.0x1cac] [New Thread 4560.0xf80] [New Thread 4560.0x1c60] [New Thread 4560.0x254] [New Thread 4560.0x1ca8] [New Thread 4560.0xbc4] [New Thread 4560.0xd54] [New Thread 4560.0x1548] [New Thread 4560.0x1d78] [New Thread 4560.0x1e34] [New Thread 4560.0x1078] [New Thread 4560.0x10d0] [New Thread 4560.0x1a1c] [New Thread 4560.0x550] [New Thread 4560.0x1ab4] [New Thread 4560.0xb6c] [New Thread 4560.0xdb8] [New Thread 4560.0x1050] [New Thread 4560.0xe20] [New Thread 4560.0x1950] [New Thread 4560.0x1820] [New Thread 4560.0xcc8] [New Thread 4560.0xfe4] [New Thread 4560.0x1fb0] [New Thread 4560.0x1aa4] [New Thread 4560.0xdd8] [New Thread 4560.0x1364] [New Thread 4560.0x1704] [New Thread 4560.0x9d4] [New Thread 4560.0x1ed0] [New Thread 4560.0x1970] [New Thread 4560.0x1b44] [New Thread 4560.0x16d4] [New Thread 4560.0x6ec] [New Thread 4560.0x60c] [New Thread 4560.0x1c50] [New Thread 4560.0x1620] [New Thread 4560.0x1d70] [New Thread 4560.0xf1c] [New Thread 4560.0x1cdc] [New Thread 4560.0x1f38] ../../gdb-7.2/gdb/printcmd.c:1916: internal-error: clear_dangling_display_expressions: Assertion `objfile->pspace == solib->pspace' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) [answered Y; input not from terminal] ../../gdb-7.2/gdb/printcmd.c:1916: internal-error: clear_dangling_display_expressions: Assertion `objfile->pspace == solib->pspace' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. Create a core file of GDB? (y or n) [answered Y; input not from terminal]

comment:6 Changed 13 years ago by seven@…

Looks pretty much the same running a debug build gdb.txt uploaded

Changed 13 years ago by seven@…

Attachment: gdb.txt added

gdb.txt debug build

comment:7 Changed 13 years ago by seven@…

I have found this normally only happens on recordings that I haven't previously watched on any frontend and has no correlation to the watched flag being set, is there something happening during recording playback that would cause this? maybe due to the preview generation?

comment:8 Changed 13 years ago by seven@…

I can confirm that so far the attached patch compiles is working great!

comment:9 Changed 12 years ago by Raymond Wagner

Owner: set to sphery

Untested patch reported as a working solution, however comment 3 indicates a move from dispatchNow() to dispatch() could cause problems with audio device control.

comment:10 Changed 12 years ago by Raymond Wagner

Status: infoneeded_newnew

comment:11 Changed 12 years ago by Raymond Wagner

Status: newassigned

Changed 12 years ago by sphery

Not-completely-updated patch referenced in comment:3

Changed 12 years ago by sphery

mythplugins portion of not-completely-updated version of patch referenced in comment:3

comment:12 Changed 12 years ago by sphery

Milestone: 0.25

It seems Paul's comment:3 was referring to http://code.mythtv.org/trac/attachment/ticket/4222/072-musichide.patch on ticket #4222 , which removed use of dispatchNow() from MythMusic. It didn't modify sendPlaybackStart() and sendPlaybackEnd() in util.cpp. However, on May 15, 2010 Paul pastebin'ed ( http://pastebin.com/k40S8FQe ) a patch to remove the use of dispatchNow() in sendPlaybackStart/End() functions.

Attached is an updated version of Paul's pastebin patch with updated file locations for current master . It doesn't compile since util.cpp has since been moved to libmythbase, which doesn't have access to libmyth/mythcontext.h and libmyth/mythplugin.h (which would create a circular dependency). The MythMusic changes incorporating the pause/resume functionality are in a separate patch file. I'm attaching these primarily so others can comment on the approach or suggest better approaches before I spend any time trying to update them for the current MythTV design.

comment:13 Changed 12 years ago by beirdo

Milestone: unknown

comment:14 Changed 12 years ago by sphery

After fixing, ref 85ac156239

comment:15 Changed 12 years ago by seven@…

Upgraded too 0.25 and so far have not experienced this issue

37-geb7e73e from http://members.iinet.net.au/~davco/

comment:16 Changed 12 years ago by JYA

Owner: changed from sphery to JYA
Status: assignedaccepted

comment:17 Changed 11 years ago by stuartm

Milestone: unknown0.27
Resolution: Fixed
Status: acceptedclosed

Appears to be fixed, if not in 0.26 then almost certainly in 0.27 where dispatchNow() has been eliminated.

Note: See TracTickets for help on using tickets.