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?)
sorry not enough information for a bug fix, I need the line where it crashes and values of variables...
Marteb
this is all what I get or do I am something wrong?
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
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
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
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
please add to the Big Buffer log line a %d and the argument haveToCopy.
Something weird is going on.
Marten
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
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.
Quote from: MartenR on February 13, 2013, 07:27:07
Please post also the Big buffer line from your code.
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
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
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
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
No, I do not think there is a way, I do not get information from the firmware if everything is ok
It is also very likely, that the firmware crashes with a damaged recording and that you need a reboot.
Marten