Version: (using KDE 3.5.9) Installed from: Compiled From Sources Compiler: gcc 4.1.2 gcc (GCC) 4.1.2 (Gentoo 4.1.2 p1.0.2) OS: Linux Konqueror will SIGSEGV at startup after following these steps: step1: mkdir -p /tmp/k/k step2: touch /tmp/k/z.sh step3: konqueror /tmp/k/* step4: click cancel, when konqueror asks wether or not you want to execute the shellscript It is important that the shellscript doesn't end up first in the url list to konqueror. I believe this code to be responsible: konq_mainwindow.cc:2680:void KonqMainWindow::openMultiURL( KURL::List url ) konq_mainwindow.cc-2681-{ konq_mainwindow.cc-2682- KURL::List::ConstIterator it = url.begin(); konq_mainwindow.cc-2683- KURL::List::ConstIterator end = url.end(); konq_mainwindow.cc-2684- for (; it != end; ++it ) konq_mainwindow.cc-2685- { konq_mainwindow.cc-2686- KonqView* newView = m_pViewManager->addTab(); konq_mainwindow.cc-2687- Q_ASSERT( newView ); konq_mainwindow.cc-2688- if (newView == 0L) continue; konq_mainwindow.cc-2689- openURL( newView, *it,QString::null); //-----> in case of a shell script it doesn't create a frame of sorts? konq_mainwindow.cc-2690- m_pViewManager->showTab( newView ); //-----> this will crash when trying to show the inexistent tab. konq_mainwindow.cc-2691- focusLocationBar(); konq_mainwindow.cc-2692- m_pWorkingTab = 0L; konq_mainwindow.cc-2693- } konq_mainwindow.cc-2694-} konq_mainwindow.cc-2695- backtrace: #6 0xb70435ca in QTabWidget::currentPageIndex () from /usr/qt/3/lib/libqt-mt.so.3 #7 0xb7043622 in QTabWidget::currentPage () from /usr/qt/3/lib/libqt-mt.so.3 #8 0xb7efe412 in KonqViewManager::showTab () from /usr/kde/3.5/lib/libkdeinit_konqueror.so #9 0xb7f08075 in KonqMainWindow::openMultiURL () from /usr/kde/3.5/lib/libkdeinit_konqueror.so #10 0xb7f1d240 in kdemain () from /usr/kde/3.5/lib/libkdeinit_konqueror.so I'm guessing the openURL destroys the created tab in some way, when dealing with executables, or other files he will not display, only it then shouldn't try to show that destroyed tab? adding a check after the openURL seems like the logical fix. Hope this helps.
thank you for that excellent bug report, but can't reproduce on svn trunk 818883 (~4.1 beta)