Mythfrontend crashed when deleting from exit recording prompt

[Tapio Sami <tapio.sami@…>]

I was at Watch Recordings, a show was recording and I noticed it to be rerun, so I selected it, it started to play. I escaped, got the menu to select what to do, chose the delete recording, confirmed it. FE crashed. The recording was not deleted.

htpc:/home/mythtv# mythbackend --version Please include all output in bug reports. MythTV Version : 21210M MythTV Branch : trunk Network Protocol : 46 Library API : 0.22.20090811-1 QT Version : 4.5.2 Options compiled in:

linux debug using_alsa using_backend using_dvb using_frontend using_hdpvr using_iptv using_mheg using_opengl_video using_opengl_vsync using_qtwebkit using_v4l using_x11 using_xv using_xvmc using_xvmc_vld using_xvmcw using_bindings_perl using_bindings_python using_opengl using_vdpau using_ffmpeg_threads using_live using_mheg

[stuartm]

Changing this to 'Video Playback'. The crash occurs as we are tearing down the video player and may be VDPAU/OpenGL related, there is an nvidia lib involved. I can't see anything in there to do with the ui or watch recordings screen after play is selected, we haven't even left playback according to the log so it doesn't match up with the description of events.

[Tapio Sami <tapio.sami@…>]

Exiting livetv, crash happened like in previous report on this ticket.

[Tapio Sami <tapio.sami@…>]

backtrace for it

[Tapio Sami <tapio.sami@…>]

Exiting recording, the screen keeps the theme background color. The same way as in other report in this ticket.

[Tapio Sami <tapio.sami@…>]

the backtrace for this crash.

[Tapio Sami <tapio.sami@…>]

Exiting recording, choosing delete, confirmed delete, screen stays dark after that. The same way as in other reports in this ticket.

[Tapio Sami <tapio.sami@…>]

Log for the crash. Exit recording, delete it, confirm delete, FE got stuck.

[Tapio Sami <tapio.sami@…>]

This latest crash is with following version.

htpc:/home/mythtv# mythbackend --version Please include all output in bug reports. MythTV Version : 21270M MythTV Branch : trunk Network Protocol : 46 Library API : 0.22.20090813-1 QT Version : 4.5.2 Options compiled in:

linux debug using_alsa using_backend using_dvb using_frontend using_hdpvr using_iptv using_mheg using_opengl_video using_opengl_vsync using_qtwebkit using_v4l using_x11 using_xv using_xvmc using_xvmc_vld using_xvmcw using_bindings_perl using_bindings_python using_opengl using_vdpau using_ffmpeg_threads using_live using_mheg

[stuartm]

Refs #6786

[tapio.sami@…]

I've got 2 more backtraces. Those were produced by exiting from a video. Not the recording of BE, but some downloaded video. Using internal player. Can't remember for sure, if I was exiting the video myself, or if the video was just played to the end....

mythtv@htpc:~/bugreport/new$ mythbackend --version Please include all output in bug reports. MythTV Version : 21743M MythTV Branch : trunk Network Protocol : 48 Library API : 0.22.20090908-1 QT Version : 4.5.2 Options compiled in:

linux debug using_alsa using_backend using_dvb using_frontend using_hdpvr using_iptv using_mheg using_opengl_video using_opengl_vsync using_qtwebkit using_v4l using_x11 using_xv using_xvmc using_xvmc_vld using_xvmcw using_bindings_perl using_bindings_python using_opengl using_vdpau using_ffmpeg_threads using_live using_mheg

[tapio.sami@…]

This crash might be related. I was exiting livetv, ended up segfaulting frontend. I botched up the myth.log, so I've only got backtrace from the crash.

[tapio.sami@…]

backtrace.

[tapio.sami@…]

Oh, forgot this.

mythtv@htpc:~/bugreport$ mythbackend --version Please include all output in bug reports. MythTV Version : 21873M MythTV Branch : trunk Network Protocol : 48 Library API : 0.22.20090912-2 QT Version : 4.5.2 Options compiled in:

linux debug using_alsa using_backend using_dvb using_frontend using_hdpvr using_iptv using_mheg using_opengl_video using_opengl_vsync using_qtwebkit using_v4l using_x11 using_xv using_xvmc using_xvmc_vld using_xvmcw using_bindings_perl using_bindings_python using_opengl using_vdpau using_ffmpeg_threads using_live using_mheg

[markk]

The more I look at these logs and backtraces, the more I'm baffled.

I'm certainly not ruling out a MythTv? issue, but can you run memtest or similar on your machine and confirm you're not seeing any other symptoms of system/memory instability. These backtraces, in combination with the problems you're seeing in other tickets, strongly hint at hardware issues.

thanks, Mark

[Tapio Sami <tapio.sami@…>]

I did run memtest for over 24h when I purchased these memory sticks less than year ago. And I am willing to do just about anything to help fix these problems: I'm running it again. I might not get the chance to run it continuosly so long, but I'll put it memtesting whenever there's no recordings to do. I'll report back within a week, after I've done a lot memtesting...

[Tapio Sami <tapio.sami@…>]

Replying to markk:

The more I look at these logs and backtraces, the more I'm baffled.

I'm certainly not ruling out a MythTv? issue, but can you run memtest or similar on your machine and confirm you're not seeing any other symptoms of system/memory instability. These backtraces, in combination with the problems you're seeing in other tickets, strongly hint at hardware issues.

thanks, Mark

Earlier I ran 9h of memtest, then was told (in IRC) that many times it does not reveal faulty memory... Then, I started 3 parallel kernel compiles (different kernel versions) and after those were well started (in the actual compiling), I started two instances of stress. With these options: stress -c 6 -m 6 -d 6 -i 6 -t 50m and the second: stress -c 12 -m 12 -d 12 -i 12 -t 120m ... Those hogged the box with load averages being over hundred. And swap was atleast 1GB in use, when normally it's at 0kB. Stresses ended with "succesful run completed in xxxx seconds" lines... cpu did not reach 60C, motherboard did not reach 45C. Kernel compiles were succesful without errors. All this time there were 2 commflaggins running (from HD channels). Nothing crashed. Can we rule out HW failure? I'm running debian sid, update it usually before compiling latest svn version.

[tapio.sami@…]

This does not happen all the time. Not nearly. Anyway, I started deleting some shows just to try to get a new backtrace with a very verbose frontend log. I eventually did get those.

mythtv@htpc:~$ mythbackend --version Please include all output in bug reports. MythTV Version : 22523M MythTV Branch : trunk Network Protocol : 50 Library API : 0.22.20091016-1 QT Version : 4.5.2 Options compiled in:

linux debug using_alsa using_backend using_dvb using_frontend using_hdpvr using_iptv using_mheg using_opengl_video using_opengl_vsync using_qtwebkit using_v4l using_x11 using_xv using_xvmc using_xvmc_vld using_xvmcw using_bindings_perl using_bindings_python using_opengl using_vdpau using_ffmpeg_threads using_live using_mheg

[tapio.sami@…]

The verbose backtrace and FE log from version 22523

[Sami Tapio <tapio.sami@…>]

After some suggestions to the functioning of my distro (Debian), I followed the suggestions to try for example mythbuntu. I have built myth on mythbuntu 9.10, here is the info.

mythtv@htpc:~$ mythbackend --version Please include all output in bug reports. MythTV Version : 22721 MythTV Branch : branches/release-0-22-fixes Network Protocol : 50 Library API : 0.22.20091023-1 QT Version : 4.5.2 Options compiled in:

linux debug using_alsa using_pulse using_backend using_dvb using_frontend using_hdpvr using_iptv using_mheg using_opengl_video using_opengl_vsync using_qtwebkit using_v4l using_x11 using_xrandr using_xv using_xvmc using_xvmc_vld using_xvmcw using_bindings_perl using_bindings_python using_opengl using_vdpau using_ffmpeg_threads using_live using_mheg

Either this has been fixed or the fault was with my installation. I tried to reproduce this, deleted perhaps 30 shows, but everything worked smoothly. In my opinion, this ticket can be closed. Thanks for the effort.

[sphery]

Reporter is unable to reproduce.