Registered Member
|
kdenlive 1650 This is a boating video. After 20 minutes of very nice work, Kdenlive crashed. Notice these strange messages: gdb kdenlive The files are present and include UTF-8 values. Now valgrind --leak-check=full --log-file-exactly=log.txt -v kdenlive: |
Registered Member
|
Could someone be so kind to help me find the problem. JB is busy these last days and I am stuck with Kdenlive 0.6 svn, waiting for a fix. Kdenlive worked very well during 30 minutes, this should be a small fix in kdenlive code. I cannot fix it myself due to a lack of knowledge in C++. |
Registered Member
|
Based on the last error in the valgrind log, it is following an uninitialised function pointer. There are a few different indirect function calls in there. Unfortunately the log doesn't report On the other hand, the gdb trace suggests it is dying in consumer_sdl_still which is in MLT. The valgrind logs report a problem at the same line here too. It seems that sdl_screen->pixels is not Alternately, it could be that the memory that ->pixels points to was freed, but too long ago for |
Registered Member
|
Thank you very much for your help. Kind regards and thank you for your help, |
Registered Member
|
I recompiled Kdenlive with debugging support. MLT has debugging by default. Here is the Valgrind trace: |
Registered Member
|
The setSceneList error doesn't appear in that log. Maybe we should just ignore it for now. The consumer_sdl_still problem occurs exactly the same. I just noticed that the bad address is ASCII. The don't look very much like text, but could be a temporary file name. So it seems that something is corrupting sdl_screen. When running under gdb, after it crashes, it might be worth doing to see how much of the structure is corrupted. What we really need to do is find out where it gets corrupted. gdb has 'watchpoints' that might Otherwise, you probably need to start sprinkling printfs around to try to find out when |
Registered Member
|
Thank you very much for this custom gdb course. It will help me to debug and (why not?) learn programming: Quote:
(gdb) up |
Registered Member
|
In Kdenlive, debugging was stripped, right? |
Registered Member
|
No, kdenlive binay is 53 Mb. It does not seem to be stripped. |
Registered Member
|
Remote debugging like this is very hard. It tends to be a very tight cycle of Doing it on a forum would be very slow, so I encourage you to explore a bit, make mistakes, try to understand what is happening. The value of 'pixels' doesn't look at all like the address that was reported as causing the error, which is odd. Maybe valgrind got confused somehow. 0x2aaaabd0b000 looks like it might be an address in global data for a shared library or something like that. The clip_rect in the data you printed out looks odd: height == 1. Maybe something is wrong there. Find out what variables control the size of the display, The problem seems to be happening at the border between MLT and SDL. It wouldn't hurt to grab the source for the SDL library and see what it happening on that side of the fence. |
Registered Member
|
Too difficult for me if the bug lays at the border of Kdenlive, MLT and xlibmesa. |
Registered Member
|
This bug doesn't seem easy to track. One thing you can try is playing your project file through MLT's command line player: inigo your_project_file.kdenlive Does it work or does it also crash ? regards |
Registered Member
|
j-b-m wrote:
This bug doesn't seem easy to track. One thing you can try is playing your project file through MLT's command line player: inigo can play the project file without problem.
j-b-m wrote:
I can create an empty project, add all clips in the project tree. Save and Open without problem. Thanks for your help. |
Registered Member
|
I cannot remove transitions easily. Shall I send you the entire project? |
Registered Member
|
When opening the project, the error now is: Quote:
kdenlive: ********** FREED MEM FOR: marc_touati2007.05.29_11-48-25.avi, COUNT: 0 |
Registered users: Bing [Bot], Google [Bot], q.ignora, watchstar