Version: 2.12 (using 4.2.3 (KDE 4.2.3), MinGW 3.4.5) Compiler: gcc.exe OS: Microsoft Windows (i686) release 6.0 (Vista Professional) Every time I open Ark and click either the open button in the toolbar or the option under the file menu, Ark becomes unresponsive and starts consuming large quantities of memory. At least as much as the machine has - and then of course I have to kill it. I attached gdb before hitting the button and what I got was: [Switching to thread 4484.0x1834] (gdb) continue Continuing. [New thread 4484.0x184c] warning: Critical:QPixmap::toWinHBITMAP(), failed to create dibsection (The parameter is incorrect.) <repeats for several hundred lines> Program exited with code 01. The last line is me killing it. It doesn't seem to be able to stop itself when this happens. I can still open archives via Dolphin and Ark opens them with no problem, so I assume it's having trouble with a directory list in the file open dialog. Actually, I just tried to press the open button in kcachegrind and the same thing happened, so that seems even more likely.
When you first start GDB, the process is stopped, you can type "bt full" to get a backtrace of the freeze. Thanks
The problem is that it's not really a freeze. It is running and consuming all the memory it can get its hands on. I haven't used GDB in years - is there any good way to step into the KDE code when I land on standard Windows libraries when I attach? It seems to be spending most of its time somewhere in ntdll.dll and single-stepping through looks like it would take hours with no debug information.
Does it only happen with Ark, or does any KDE program do that when you open a file with them?
I can get it to happen in kcachegrind as well, but all the other programs with a file open dialog seem to be OK.