Bug 52516 - konqueror crashes often
Summary: konqueror crashes often
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Public Beta
Classification: Retired
Component: kdebase   
(Show other bugs)
Version: roswell
Hardware: ia64
OS: Linux
medium
high
Target Milestone: ---
Assignee: Bernhard Rosenkraenzer
QA Contact: Ben Levenson
URL:
Whiteboard:
Keywords:
: 53521 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2001-08-24 16:06 UTC by Need Real Name
Modified: 2007-04-18 16:36 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-10-19 20:43:05 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
traceback from konqueror (default locale = ja_JP.eucJP) (3.00 KB, text/plain)
2001-08-28 19:22 UTC, Ben Levenson
no flags Details

Description Need Real Name 2001-08-24 16:06:37 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.77 [en] (X11; U; Linux 2.4.7-2smp i686)

Description of problem:
konquerer crashes in many circumstances,
bringing up the crash handler window.

I have not been able to determine exactly what
sequence of actions will cause it _not_ to crash
but some sequences do exist.

Version-Release number of selected component (if applicable):


How reproducible:
Sometimes

Steps to Reproduce:
1.click on the konqueror icon in the panel

or

1.type "konqueror" on the command line
2.click in the location field
	

Actual Results:  The crash handler came up, I clicked "close",
and the KDE window went away.

Expected Results:  The program should have allowed me to proceed
with normal operation.

Additional info:

If I run konquerer as a file manager by
clicking on the home directory button on the
panel, I have _sometimes_ managed to get it
out of the state in which it crashes, by
navigating with the sidebar and clicking on 
folders and such. I have not been able to
reproduce that scenario, however.

Comment 1 Ben Levenson 2001-08-28 19:22:53 UTC
Created attachment 29935 [details]
traceback from konqueror (default locale = ja_JP.eucJP)

Comment 2 Martin Wilck 2001-09-07 17:51:06 UTC
I might add: kspread crashes when it is first opened (empty document), kword
hangs when
first opened (empty document). I am not a KDE user and have other duties here,
so this was just
a quick scan, but rather disastrous.


Comment 3 Bernhard Rosenkraenzer 2001-09-11 09:11:55 UTC
*** Bug 53521 has been marked as a duplicate of this bug. ***

Comment 4 Bernhard Rosenkraenzer 2001-09-11 09:13:44 UTC
This is almost certainly a compiler bug since it works everywhere else (even 
on other 64-bit arches: alpha, s390x).
Adding Cc.



Comment 5 Jakub Jelinek 2001-09-11 09:19:25 UTC
This needs to be retested when all of kde is rebuilt with gcc-2.96-98 and above.

Comment 6 Ben Levenson 2001-10-18 16:37:31 UTC
I rebuilt and reinstalled the following RPMS and still received a backtrace.
 kdeutils-2.2-3
 kdelibs-2.2-11
 kdebase-2.2-13
 kdeadmin-2.2-9
 kdelibs-sound-2.2-11
---------------------
0x200000000204a542 in wait4 () at soinit.c:56
    in soinit.c
#0  0x200000000204a542 in wait4 () at soinit.c:56
#1  0x200000000204a4c0 in __libc_waitpid (pid=10528, stat_loc=0x0, options=0)
    at ../sysdeps/unix/sysv/linux/waitpid.c:26
#2  0x2000000000dd3180 in KCrash::defaultCrashHandler ()
   from /usr/lib/libkdecore.so.3
#3  <signal handler called>
---------------------
FWIW, I also rebuilt the qt RPMS, but to no avail.
Konqueror will open web pages if I click on the desktop links. I can surf
as long as I use the mouse, but it segfaults as soon as I try to type something
in the address bar.
I have an strace (from konqueror --nocrashhandler if it is useful)


Comment 7 Ben Levenson 2001-10-19 19:22:07 UTC
I've received the same backtrace while using kmail as well.

Comment 8 Josep Guallar-Esteve 2001-10-19 19:36:22 UTC
I think that 53522 is actually the same bug.


Comment 9 Jakub Jelinek 2001-10-19 20:43:00 UTC
If all backtraces have XCreateIC in close above the segfault,
it might as well be the infamous "thou shalt not mix 0 and NULL
arguments to varargs functions on IA-64", since XCreateIC is a
varargs function. Typically:
foo(A a, ...) { ; while (va_arg (v, void *)) != NULL) { } }
bar() { ; foo(1, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0); }
would work on all arches but IA-64, where that 0 might result in
garbage in upper 32 bits on the stack.
Looking at XCreateIC, it e.g. calls _XIMCountVaList which does
exactly that, dunno what Qt is actually doing, can somebody please
check it out (be it under debugger or by source inspection)?

Comment 10 Ngo Than 2001-10-19 21:15:06 UTC
update qt-2.3.1-7 fixes this problem.


Note You need to log in before you can comment on or make changes to this bug.