Opened 14 years ago

Closed 14 years ago

#466 closed defect (fixed)

SEGV mythfrontend while attempting edit recording

Reported by: Stuart Auchterlonie Owned by: Isaac Richards
Priority: minor Milestone: 0.19
Component: mythtv Version: head
Severity: medium Keywords: segv mythfrontend
Cc: Ticket locked: no

Description

Managed to crash the frontend while attempting to edit an existing recording.

BT is attached.

Attachments (1)

frontend-bt.txt (3.6 KB) - added by Stuart Auchterlonie 14 years ago.
backtrace of frontend death.

Download all attachments as: .zip

Change History (3)

Changed 14 years ago by Stuart Auchterlonie

Attachment: frontend-bt.txt added

backtrace of frontend death.

comment:1 Changed 14 years ago by danielk

(In [7583]) References #466.

This cleans up the function where the crash actually a happened a bit. But I don't know what actually caused the crash, so this just makes the backtrace look better.

A new backtrace is needed of course.

But it would also be useful to know what edit keys were actually hit and what the aspect ratio of the video and screen were, and if there was a letterbox mode in effect. And what the resolution of the video and screen were.

comment:2 Changed 14 years ago by Stuart Auchterlonie

Resolution: fixed
Status: newclosed
Summary: SEGV mythfronend while attempting edit recordingSEGV mythfrontend while attempting edit recording

Initial testing doing exactly what I was doing before on the exact same recording it no longer crashed. But the frontend log did generate quite a lot of

[mpeg2video @ 0xb75a8270]warning: first frame is no keyframe

and at roughly the point where it was crashing it also showed

[dvbsub @ 0xb75a8270]Junk in packet
[dvbsub @ 0xb75a8270]Invalid object location!

The action I was performing at the time was hit 'e' for edit.

The most relevant part of the earlier backtrace I found was

http://svn.mythtv.org/trac/attachment/ticket/466/frontend-bt.txt#L29

this shows that drawwidth had gone negative. Debugging showed me at the time that the xstart was exceeding the width of the surface.

From osdtypes.cpp, rev 7582, line 945-946

    if (drawwidth + xstart > surface->width)
        drawwidth = surface->width - xstart - 1;

This calculation caused drawwidth to go negative when xstart > surface->width which memcpy didn't like very much.

Looks like you have reworked the relevant area of the code to prevent this condition and therefore the crash.

Note: See TracTickets for help on using tickets.