Windows frontend ASSERT failure in QCoreApplication::sendEvent

[seven@…]

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.

[danielk]

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.

[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 .

[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.)

[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.

[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]

[seven@…]

18MB log file

​https://docs.google.com/leaf?id=0B0wIeMakO7HCNjg1NDAwNjgtN2NlNS00MTViLTkxODUtZDFkNjRkNDk4NjAx&hl=en_US&authkey=CIuHwvoD

[seven@…]

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

[seven@…]

gdb.txt debug build

[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?

[seven@…]

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

[Raymond Wagner]

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

[sphery]

Not-completely-updated patch referenced in comment:3

[sphery]

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

[sphery]

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.

[sphery]

After fixing, ref 85ac156239

[seven@…]

Upgraded too 0.25 and so far have not experienced this issue

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

[stuartm]

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