I forgot to add that Ark works fine in my two other TDE environments.

This still looks like it happens deep within the system libraries.

Are you sure this is a SIGSEGV?  Could it be a SIGABRT or bad file descriptor instead?

You'll have to help me to answer your question. I don't understand those terms. :)

All I know is when Ark crashes I get the crash dialog box on screen. I selected the Backtrace tab and pasted the results here.

Let me know what details you need!

More info: I use the same TDE hard drive partition in a 350 MHz PII with 448 MB of RAM. (Removable hard drive bays. :) ) No crashing with that box. Could (a lack of) memory be the problem? I have a 1GB swap partition.

Also of possible note: I had to build a special (2.6.33.15) kernel because the K6-III+ CPU in the PI machine does not support PAE and CMOV. There could be kernel related issues involved. I have no problems with KDE3 and the 2.6.27.59 kernel, and that is a special kernel build too.

I ran Ark again on the PI box. This time I selected a small archive file. Ark opened but upon closing I received the crash dialog. Here is the backtrace created by that:

======================================================
[Thread debugging using libthread_db enabled]
[KCrash handler]
#5  ~QMetaObjectCleanUp (this=0xb78a7604, __in_chrg=<value optimized out>)
    at kernel/qmetaobject.cpp:1238
#6  0xb6136fdf in exit () from /lib/libc.so.6
#7  0x0804e791 in launch (argc=<value optimized out>,
    _name=<value optimized out>, args=<value optimized out>, cwd=0x0, envc=1,
    envs=0x80a4659 "DISPLAY=:0.0", reset_env=false, tty=0x0,
    avoid_loops=false,
    startup_id_str=0x80a466a "testbox;1325015465;506700;2640_TIME292344")
    at /dev/shm/kdelibs/kinit/kinit.cpp:673
#8  0x0804f4d1 in handle_launcher_request (sock=9)
    at /dev/shm/kdelibs/kinit/kinit.cpp:1240
#9  0x0804fbde in handle_requests (waitForPid=<value optimized out>)
    at /dev/shm/kdelibs/kinit/kinit.cpp:1443
#10 0x080510e8 in main (argc=5, argv=0xbfa3ff04, envp=0xbfa3ff1c)
    at /dev/shm/kdelibs/kinit/kinit.cpp:1908
======================================================

I had been opening the archived files from within Konquror. Curious, I opened the same archive file using KRunner. No crash with opening or closing Ark. I repeated both methods three times. Opening from within Konqueror resulted in a crash every time. I thought I was on to something but then on the third try with KRunner Ark failed to open and I received a crash. Here is the backtrace created:

======================================================
[Thread debugging using libthread_db enabled]
[KCrash handler]
#5  0xb6919e77 in KConfigINIBackEnd::parseSingleConfigFile (this=0x8071db0,
    rFile=..., pWriteBackMap=0xbf909c4c, bGlobal=true, bDefault=false)
    at /dev/shm/kdelibs/kdecore/kconfigbackend.cpp:516
#6  0xb691b946 in KConfigINIBackEnd::getEntryMap (this=0x8071db0,
    aTempMap=..., bGlobal=<value optimized out>, mergeFile=0x8172530)
    at /dev/shm/kdelibs/kdecore/kconfigbackend.cpp:987
#7  0xb691bd2f in KConfigINIBackEnd::writeConfigFile (this=0x8071db0,
    filename=..., bGlobal=<value optimized out>, bMerge=true)
    at /dev/shm/kdelibs/kdecore/kconfigbackend.cpp:1040
#8  0xb691c4e0 in KConfigINIBackEnd::sync (this=0x8071db0, bMerge=true)
    at /dev/shm/kdelibs/kdecore/kconfigbackend.cpp:881
#9  0xb69071f7 in KConfigBase::sync (this=0x8071c98)
    at /dev/shm/kdelibs/kdecore/kconfigbase.cpp:1767
#10 0xb6da25dd in KMainWindow::saveAutoSaveSettings (this=0x8052848)
    at /dev/shm/kdelibs/kdeui/kmainwindow.cpp:1054
#11 0xb6da2cc0 in KMainWindow::qt_invoke (this=0x8052848, _id=71,
    _o=0xbf909e58) at /dev/shm/kdelibs.build/kdeui/kmainwindow.moc:138
#12 0xb729053b in KParts::MainWindow::qt_invoke (this=0x8052848, _id=71,
    _o=0xbf909e58) at /dev/shm/kdelibs.build/kparts/mainwindow.moc:98
#13 0xb7737cb9 in MainWindow::qt_invoke (this=0x8052848, _id=71, _o=0xbf909e58)
    at mainwindow.moc:181
#14 0xb636ade5 in QObject::activate_signal (this=0x8138e18, clist=0x80a0fe8,
    o=0xbf909e58) at kernel/qobject.cpp:2383
#15 0xb636cec6 in QObject::activate_signal (this=0x8174fc0, signal=2)
    at kernel/qobject.cpp:2352
#16 0xb6699b38 in QTimer::timeout (this=0x8138e18)
    at .moc/release-shared-mt/moc_qtimer.cpp:82
#17 0xb638ddff in QTimer::event (this=0x8138e18, e=0xbf90a108)
    at kernel/qtimer.cpp:222
#18 0xb630776d in QApplication::internalNotify (this=0x8055568,
    receiver=0x8138e18, e=0xbf90a108) at kernel/qapplication.cpp:2638
#19 0xb63086bc in QApplication::notify (this=0x8055568, receiver=0x8138e18,
    e=0xbf90a108) at kernel/qapplication.cpp:2375
#20 0xb68e3c5d in KApplication::notify (this=0x8055568, receiver=0x8138e18,
    event=0xbf90a108) at /dev/shm/kdelibs/kdecore/kapplication.cpp:582
#21 0xb62fd267 in QApplication::sendEvent (this=0x807bcb8)
    at kernel/qapplication.h:523
#22 QEventLoop::activateTimers (this=0x807bcb8)
    at kernel/qeventloop_unix.cpp:559
#23 0xb62b5335 in QEventLoop::processEvents (this=0x807bcb8, flags=4)
    at kernel/qeventloop_x11.cpp:392
#24 0xb631fc0b in QEventLoop::enterLoop (this=0x807bcb8)
    at kernel/qeventloop.cpp:201
#25 0xb631faa4 in QEventLoop::exec (this=0x807bcb8)
    at kernel/qeventloop.cpp:148
#26 0xb6307df1 in QApplication::exec (this=0x8055568)
    at kernel/qapplication.cpp:2761
#27 0xb7732326 in kdemain (argc=2, argv=0xbf90a494) at main.cpp:125
#28 0x080484eb in main (argc=2, argv=0xbf90a494) at ark.la.cpp:2
======================================================

I wish I knew how to read backtraces or at least deduce where the problem is lies. :)

I hope this additional information helps.

Closing as works for me. I no longer can replicate the bug.