Hi
It seems that there is some memory problems with mplayercluster plugin when using NFS-path mapping and the server side path gets big enough. I did some testing and noticed that the critical length of the file path is somewhere near 58 characters. Exeeding that the VDR crashes every time. The standard output from VDR looks like this when trying to play a file that's remote path is "/mnt/media/movies/The Office/The Office - S - Downsize.avi":
cretincreting 137789880 sende initpaket ende initpaket deleting 137789880 nach delete *** glibc detected *** malloc(): memory corruption: 0x083682a0 ***
If I shorten the filename the file plays OK and VDR stays running.
I'm using VDR-1.3.42 and I have patched the plugin with "mplayercluster-0.0.1a-Urig8.diff"
I'll try to debug the plugin and see if I can find out more information about this.
-- t.
Teppo Jalava wrote:
It seems that there is some memory problems with mplayercluster plugin when using NFS-path mapping and the server side path gets big enough. I did some testing and noticed that the critical length of the file path is somewhere near 58 characters.
All these strings are dynamically allocated, either in the (local) cString class or malloc'ed with exact size, so I dont think that this is a simple buffer overflow.
deleting 137789880 nach delete *** glibc detected *** malloc(): memory corruption: 0x083682a0 ***
(1) the delete is commented out for some reason, so this cant be causing it. (2) this is the last message of the init part, so the bug may be somewhere in the main loop.
I'll try to debug the plugin and see if I can find out more information about this.
Anything helpful would be very welcome. Add some more debug messages or try to locate the crash with a debugger.
Cheers,
Udo
On 2/18/06, Udo Richter udo_richter@gmx.de wrote:
All these strings are dynamically allocated, either in the (local) cString class or malloc'ed with exact size, so I dont think that this is a simple buffer overflow.
(1) the delete is commented out for some reason, so this cant be causing it. (2) this is the last message of the init part, so the bug may be somewhere in the main loop.
Anything helpful would be very welcome. Add some more debug messages or try to locate the crash with a debugger.
I think I've found the problem. In transceiver.c, on line 163 filenameLen should be changed to remoteFilename.length(), since filenameLen is in network byte order. So it after all wasn't a very big fix, but still I managed to spend way too much time debuggin before I noticed that ;)
I attach a patch againts "mplayercluster-0.0.1a-Urig8.diff"-patched version with the fix. I also uncommented the delete[] line, since it doesn't cause any problems, at least for me.
-t
Teppo Jalava wrote:
I think I've found the problem. In transceiver.c, on line 163 filenameLen should be changed to remoteFilename.length(), since filenameLen is in network byte order. So it after all wasn't a very big fix, but still I managed to spend way too much time debuggin before I noticed that ;)
Hmm, you're absolutely right. I'll include that for next release.
Cheers,
Udo
-
Teppo Jalava -
Udo Richter