Menu

#101 drip crash right after autoclipper done

open-remind
3
2003-03-24
2002-08-20
No

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."

Discussion

  • Katherine Six Harvest

    Logfile from crash

     
  • Jarl van Katwijk

    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;)

     
  • Jarl van Katwijk

    • labels: 321613 --> 3th party dependancies
    • priority: 5 --> 3
    • status: open --> open-wont-fix
     
  • Katherine Six Harvest

    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.

     
  • Katherine Six Harvest

    drip.log file from crash using several different codecs

     
  • Jarl van Katwijk

    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;)

     
  • Katherine Six Harvest

    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?

     
  • Katherine Six Harvest

    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. :)

     
  • Jarl van Katwijk

    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;)

     
  • Jarl van Katwijk

    • status: open-wont-fix --> open-remind
     
  • Katherine Six Harvest

    Compilation log showing the errors I'm getting

     
  • Katherine Six Harvest

    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

     
  • Katherine Six Harvest

    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.

     
  • Katherine Six Harvest

    Logs from failed session retry...

     
  • Katherine Six Harvest

    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.

     

Log in to post a comment.