I reported this problem before using the support link
but haven't gotten
any solutions that have worked so far.
This problem has occured for me with drip 0.8.2pre1,
pre2 and several CVS downloads from between the two.
It occurs with avifile 0.7.7, 0.7.11, and 0.7.13
through 15 for me (those are the only ones I've tried,
it may exist with others).
The problem is that for some reason every time I try an
encode, drip
crashes immediately after the autoclipper finishes
taking its five
samples. If I turn off the autoclipper, it crashes at
the point where the
autoclipper would normally start (i.e. immediately
after opening the
cached VOB's for input).
When the crash occurs, a message in the terminal from
which drip was launched appears which reads "Gdk-ERROR
**: Fatal IO error 9 (Bad file descriptor) on X server
:0.0."
Screenshot of launching xterm
Logfile from crash
Logged In: YES
user_id=184138
The codec you're using wwith avifile somehow crashes, look
at these last 2 line out your log file: -------
Mon Aug 19 16:51:21 2002 | 302 | Debug | About to
initialise avifile, when Drip stops (crashes) here get
yourself a working avifile...
Mon Aug 19 16:51:21 2002 | 303 | Debug | Trying to
utilize divxf codec
----------
I suggest to use another codec, like the Xvid one. I'm not
sure why some are crashing and some are not.. these are
avifile problems I dont have enough time for to debug;)
Logged In: YES
user_id=244488
I've tried a bunch of different codecs and I get pretty much
the same crash with all of them. The one difference I've
found is with "OpenDIVX codec, ffodivx" where a crash still
does occur and in exactly the same place as always, except
with that codec instead of the whole drip dialog
disappearing from the screen I get a dialog box which reads
Application "gnomedrip" (process 16379) has crashed due to a
fatal error. (Segmentation fault)
I'm enclosing drip.log files from the crash using several
different codecs, including two versions of XviD.
drip.log file from crash using several different codecs
Logged In: YES
user_id=184138
When you've got this dialog box about Drip crashing, could
you do Next and copy-paste the text about the crash into a
reply here? It might give me a hint where to start debugging;)
Logged In: YES
user_id=244488
There isn't a "Next" in the dialog box, there's only a
"Close" and when I click it no new text appears in drip or
in the launching xterm. Interestingly enough, when I click
it drip doesn't close, either, it just sits there in a
frozen state until I killall gnomedrip, at which point the
launching xterm shows the message "/usr/local/bin/drip: line
6: 21550 Terminated gnomedrip". Does *that*
provide any clues?
Logged In: YES
user_id=244488
Hi -- This is really silly, but I thought I should write in
about it anyway. I seem to have fixed this problem by
adding an "#include <stdio.h>" immediately above the
function CodecSetAttr in lib/codeckeeper.cpp off the root
directory of avifile. I have no idea why that would fix the
problem, but it apparently did and drip now works great for
me. :)
Logged In: YES
user_id=184138
Do you still need to add this #include <stdio.h> to newer
avifiles? If so I'll check it out, outherwise it's fixed and
I wont bother;)
Compilation log showing the errors I'm getting
Logged In: YES
user_id=244488
That's a very good question.
To be honest it's been a while since I've used your
program... I won't mention which competitor I'm with right now.
But regardless of this, I just downloaded your latest
version (the "third CVS snapshot") and tried to compile
it... Upgraded my GCC to 3.2.2 for it, got the latest
libmpeg2, figured out how to tell configure that my old
style GTK is under /usr/local/oldgtk...
/usr/local/bin/ld: Dwarf Error: Invalid or unhandled FORM
value: 14.
/usr/local/bin/ld: Dwarf Error: Invalid or unhandled FORM
value: 14.
dripencoder-external.o: In function `encoder_codecs':
/home/six/drip/encoder/external.cpp:173: undefined reference
to `avm::CodecInfo::match(unsigned, avm::CodecInfo::Media,
avm::CodecInfo const*, avm::CodecInfo::Direction)'
dripencoder-external.o: In function
`__static_initialization_and_destruction_0(int, int)':
/usr/local/newgcc/include/c++/3.2.2/iostream:63: undefined
reference to `std::ios_base::Init::Init[in-charge]()'
/usr/local/newgcc/include/c++/3.2.2/iostream:63: undefined
reference to `std::ios_base::Init::~Init [in-charge]()'
dripencoder-external.o:/home/six/drip/encoder/external.cpp:63:
undefined reference to `__gxx_personality_v0'
/usr/local/bin/ld: Dwarf Error: Invalid or unhandled FORM
value: 14.
/usr/local/bin/ld: Dwarf Error: Invalid or unhandled FORM
value: 14.
/usr/local/bin/ld: Dwarf Error: Could not find abbrev number
109.
dripencoder-fast_memcpy.o(.eh_frame+0x11): undefined
reference to `__gxx_personality_v0'
/usr/local/bin/ld: Dwarf Error: Invalid or unhandled FORM
value: 14.
/usr/local/bin/ld: Dwarf Error: Invalid or unhandled FORM
value: 14.
/usr/local/bin/ld: Dwarf Error: Invalid or unhandled FORM
value: 14.
/usr/local/bin/ld: Dwarf Error: Invalid or unhandled FORM
value: 14.
But I have *no* idea what a "Dwarf Error" is or how to
handle it.
Any tips?
...
There isn't any chance that this is happening because
despite the fact that I've told it the old GTK is in
/usr/local/oldgtk, your config script doesn't give me any
easy way to tell it the old GLIB is there too, is there?
(i.e. because it's including the GLIB from GTK2 but the old
style GTK?) Usually it bombs out with a bunch of not-found
include dirs when that's the case and I have to combine
"find" and "sed" to fix the Makefiles if I *really* want it
to work...
But I can't think of anything else off the top of my head
that could be really wrong.
Anyway, Imma attach a complete log of my compile for your
perusal.
6
Logged In: YES
user_id=244488
Alright...
Since I'm not a *complete* moron, after thinking about it
for a while I figured out that with such a weird looking
error during compile, there's probably something very odd
going on with my system. So I sat down this evening and
recompiled/upgraded a bunch of stuff (most of it not
directly related to drip) and did manage to get drip 0.9.0
CVS snapshot 3 compiled... Using AVIFile
RELEASE-0.7.34-030329-02:48-3.2.2 with it.
And it does seem to still die in more or less the same
place. The only difference seems to be that, at least if I
select either DivX 5 low motion or XviD, it leaves the drip
window open when it dies instead of shutting it down. With
DivX 3 low motion it does close the window upon dying just
like it did before.
I'm attaching a zipfile containing a typescript of what's
outputted to standard out during a run selecting DivX 5 low
motion as the codec, as well as the drip.log from the same
session and a screen capture of what the screen looks like
once it's already died (with the window frozen in place.)
As I said above, the same thing happens if I select XviD,
though with DivX 3 it closes the window instead of leaving
it open. And all these codecs work fine both for decoding
with both mplayer and xine and for encoding with several
other Linux based products.
Logs from failed session retry...
Logged In: YES
user_id=244488
Gah... File attachment rejected for being too big.
Retrying with the JPG compression level set very very tight
on the screenshot.