News:

Latest versions:
Server plugin: 0.5.1
MVP dongle: 0.5.2
Raspberry Pi client: 0.5.2
Windows client: 0.5.2-1

Main Menu

[Solved] Segmentation fault while playing hd-recording

Started by hondansx, February 09, 2013, 17:26:36

Previous topic - Next topic

hondansx

Firmware:


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



Backtrace:


[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?)
GA-EP43 | headless | 1xCineS2 Dual | 1xSkystar 2.6D | VDR 1.7.37 
Frontend: 1xRasperry | 1xION3

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?
GA-EP43 | headless | 1xCineS2 Dual | 1xSkystar 2.6D | VDR 1.7.37 
Frontend: 1xRasperry | 1xION3

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
GA-EP43 | headless | 1xCineS2 Dual | 1xSkystar 2.6D | VDR 1.7.37 
Frontend: 1xRasperry | 1xION3

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

#6
Quote from: MartenR on February 10, 2013, 11:25:02
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
GA-EP43 | headless | 1xCineS2 Dual | 1xSkystar 2.6D | VDR 1.7.37 
Frontend: 1xRasperry | 1xION3

MartenR

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

Marten

hondansx

#8
Quote from: MartenR on February 12, 2013, 15:55:25
please add to the Big Buffer log line a %d and the argument haveToCopy.
Something weird is going on.

Marten
GA-EP43 | headless | 1xCineS2 Dual | 1xSkystar 2.6D | VDR 1.7.37 
Frontend: 1xRasperry | 1xION3

MartenR

#9
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:
QuoteLog::getInstance()->log("Video", Log::DEBUG, "DMP mark 8");
to
QuoteLog::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

GA-EP43 | headless | 1xCineS2 Dual | 1xSkystar 2.6D | VDR 1.7.37 
Frontend: 1xRasperry | 1xION3

MartenR

We are close, probably the pes header is damaged. Let check this:
please add before *samplepos+=headerstrip;
The line:
QuoteLog::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

Quote from: MartenR on February 14, 2013, 07:24:55
We are close, probably the pes header is damaged. Let check this:
please add before *samplepos+=headerstrip;
The line:
QuoteLog::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
GA-EP43 | headless | 1xCineS2 Dual | 1xSkystar 2.6D | VDR 1.7.37 
Frontend: 1xRasperry | 1xION3

MartenR

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


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

Marten

hondansx

#14
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
GA-EP43 | headless | 1xCineS2 Dual | 1xSkystar 2.6D | VDR 1.7.37 
Frontend: 1xRasperry | 1xION3