Ok, I whoops'd and didn't notice my replies were going straight to
Hans instead of the list so here's the short version for anyone else
following this thread:
On Tue, Jun 21, 2011 at 1:53 AM, Hans de Goede <j.w.r.degoede(a)gmail.com> wrote:
I would make sure I've a binary compiled with debuginfo
installed, or install from rpm and install the
relevant -debuginfo packages, then run the hanging
program normally and once it hangs attach gdb to it
and see what it is doing.
Yup, I installed the avidemux-debuginfo but not all the dependencies.
I hope I don't need them as it's an extensive list.
I usually run the program from gdb, but you're saying there's a way to
attach gdb to it after the fact?
On Wed, Jun 22, 2011 at 3:45 AM, Hans de Goede <j.w.r.degoede(a)gmail.com> wrote:
[SNIP]
I don't know how to redirect the output to file I'm afraid,
although
I'm pretty sure there is a way ...
Well, I don't know why this works but it does...
I first tried:
# gdb /usr/bin/avidemux2_qt4
set logging on
set logging file avidemux.log
run
<HANG>
<CTL-C>
thread apply all bt full
quit
This saved the output of avidemux but not the backtrace.
Then I found a gentoo page[1] and they did things a little differently:
# gdb /usr/bin/avidemux2_qt4
run
<HANG>
<CTL-C>
set logging on
set logging file avidemux_bt.log
thread apply all bt full
set logging off
quit
And see if there is anything interesting there. If you can copy
paste
the output of that I can see if I notice anything special.
http://pastebin.com/iqsBF8fj
Thanks,
Richard
[1]
http://www.gentoo.org/proj/en/qa/backtraces.xml
I looked at some of the output but I didn't see anything that jumped
out at me as wrong. There must be a way to redirect the gdb output to
a file which may make it easier to browse through.
Thanks,
Richard
Update...
I don't know if you've looked at the bt yet as I've updated it twice
now :) I installed SOME of the missing debuginfo packages (at least
the ones that might actually be useful, like glibc). I didn't both
with the QT ones since it's huge and the problem is limited to the AAC
encoder so it's probably not relevant.
If you look at line 360 there seems to be a typo:
vfPlugins = 0x16aedf0 "lugins/videoEncoder/"
It looks like the P is missing but I would think that if that's the
problem then it would mess up all the encoders, not just AAC.
...
Grep'd though the source and didn't see the problem, guess it's not related.
Thanks,
Richard