[Solved] Segmentation fault while playing hd-recording

[hondansx]

Firmware:

Code Select Expand


Jan 25 2013 19:12:00
Copyright (c) 2012 Broadcom
version 365215 (release)



Backtrace:

Code Select Expand


[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
Core was generated by `./vompclient -d'.
Program terminated with signal 11, Segmentation fault.
#0  mis_1_loop () at memcpy.S:214
214 memcpy.S: Datei oder Verzeichnis nicht gefunden.
(gdb) bt full
#0  mis_1_loop () at memcpy.S:214
No locals.
#1  0x000edd40 in VideoOMX::DeliverMediaPacket (this=<error reading variable: Cannot access memory at address 0xffffffe0>,
    packet=<error reading variable: Cannot access memory at address 0x4>,
    buffer=<error reading variable: Cannot access memory at address 0x3c>,
    samplepos=<error reading variable: Cannot access memory at address 0x40>) at videoomx.cc:2738
        cancopy = <error reading variable cancopy (Cannot access memory at address 0xffffffe8)>
        headerstrip = <error reading variable headerstrip (Cannot access memory at address 0xffffffec)>
        haveToCopy = <error reading variable haveToCopy (Cannot access memory at address 0xfffffff0)>
Backtrace stopped: previous frame inner to this frame (corrupt stack?)


[MartenR]

sorry not enough information for a bug fix, I need the line where it crashes and values of variables...

Marteb

[hondansx]

this is all what I get or do I am something wrong?

[MartenR]

Well, you could load it with gdb-tui into an gdb command line ui, then it will show you where it crashed.
With the gdb commands then you can go up and down in the stack, in the function delivermediapacket, the value of variables enter into the memcpy call are crucial for me to see what is going on. There gdb commands to print them.
But it can happen that the stack is corrupt and the variables are not accessible. In that case a Log command before the memcpy should be inserted where these varaibles are Log before the crash and a new crash should be provoked.

Marten

[hondansx]

Well with my limited skills it would be better to post the coredump and/or the broken recording.
Is this an option for you?

Walter

[MartenR]

The core dump will only help, if all libraries and otherthings are the same, I doubt that this will work.

First uncomment all Log message in the DeliverMediaPacketMethod, there might be suffient debugging code already and post a log.

Marten

[hondansx]

The core dump will only help, if all libraries and otherthings are the same, I doubt that this will work.

First uncomment all Log message in the DeliverMediaPacketMethod, there might be suffient debugging code already and post a log.

Marten

[MartenR]

please add to the Big Buffer log line a %d and the argument haveToCopy.
Something weird is going on.

Marten

[hondansx]

please add to the Big Buffer log line a %d and the argument haveToCopy.
Something weird is going on.

Marten

[MartenR]

Ok, it is trying to copy a negative number of bytes into the buffer. Effectively it is  a very high number, if treated as unsigned integer.
The question is why this happens.
Please change the line:

Log::getInstance()->log("Video", Log::DEBUG, "DMP mark 8");

to

Log::getInstance()->log("Video", Log::DEBUG, "DMP mark 8 %d %d ",packet.length,*samplepos);

Let see what is happening there....
Please post also the Big buffer line from your code.

[hondansx]

Please post also the Big buffer line from your code.

[MartenR]

We are close, probably the pes header is damaged. Let check this:
please add before

Code Select Expand

*samplepos+=headerstrip;
The line:

Log::getInstance()->log("Video", Log::DEBUG, "DMP mark header %d %d %d",headerstrip,*samplepos,packet.length);

If I am right I know, how to prevent the seg fault, but then the recording is damaged.

Marten

[hondansx]

We are close, probably the pes header is damaged. Let check this:
please add before

Code Select Expand

*samplepos+=headerstrip;
The line:

Log::getInstance()->log("Video", Log::DEBUG, "DMP mark header %d %d %d",headerstrip,*samplepos,packet.length);

If I am right I know, how to prevent the seg fault, but then the recording is damaged.

Marten

This recording was produced in bad weather. Nevertheless vdr can play this fine.

Thanks for your support,
Walter

[MartenR]

Please test:

Code Select Expand

if (headerstrip>=packet.length) {
                 *samplepos=packet.length;// Packet is obviously damaged
                 return packet.length;//skip it!
}


right after:

Code Select Expand

*samplepos+=headerstrip;
if it works, it will go into git.

Marten

[hondansx]

Segfault is gone and some seconds later the recording stops playing. (Is there any chance to get any kind of reset for, to play further, like vdr does?)
So I have to press exit and start the recording again.

Walter