I tried the latest win32 mozilla build... So far it seems this bug is only reproducable in Linux.
Summary: crash when hitting CTRL-Delete more then once on the "Web Page" field → Crash when hitting CTRL-Delete more then once on the "Web Page" field at babelfish
Reassigning to Browser-General until we can get a stack trace. I am unable to reproduce the crash using Mozilla trunk 20020314xx on Linux, WinNT. Anoakie, are you using the latest Linux build? Do you have a talkback-enabled build? If you crash again, you can post the talkback incident ID here and I'll look up the stack trace. Also: what version of Linux are you using, and what is your window manager?
Assignee: rogerl → asa
QA Contact: pschwartau → doronr
I'm not using the latest linux build, I am using .99 with galeon (debian packages). I did verify it with a 20020226xx CVS build (debian package). I just installed the latest CVS nightly (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9+) Gecko/20020320, build 2002032008) and verified that it does crash. I have also just installed the talkback version of .99, but I can't get talkback to catch the crashes yet... If you can tell me how to get talkback catch the crashes with the linux version, I will post the talkback incident ID here. I'm running Linux 2.4.18 with the preempt patches and WindowMaker 0.80.0. Here is the crash data (from the latest nightly using gdb... I doubt this will help much): Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 5544)] 0x410d31d1 in NSGetModule () from /usr/lib/mozilla/components/libgklayout.so (gdb) bt #0 0x410d31d1 in NSGetModule () from /usr/lib/mozilla/components/libgklayout.so ... (too many to print here)
QA Contact: doronr → pschwartau
QA Contact: pschwartau → doronr
Anoakie: thanks, could you save your stack trace in a text file, and attach the text file to this bug via the "Create a New Attachment" link above? Thanks - it will help if we can see the whole thing. I'm not sure what to say about Talkback; I thought it came up automatically whenever you crash, so you could fill in details about what you were doing, etc. Anyway, if you can attach a stack trace, that would be great -
Attached the backtrace. I hope it helps.
There are a lot of Layout function calls in the backtrace, but let me assign this to HTML Form Controls just in case the problem is rooted there -
Assignee: asa → rods
Component: Browser-General → HTML Form Controls
QA Contact: doronr → madhur
For the "Steps to reproduce" part, #2 says: "Click in the "Web page" field". A more detailed description for #2 follows: Click on the "Web page" field ater the "http://" string. i.e. Click here: "http://[CLICK]"
Unfortunately, I still can't reproduce this crash, using Mozilla trunk binaries from 2002-03-23 on Linux, WinNT, and Mac9.1. On my Linux box, I am running Red Hat 6.1 and Window Maker 0.61 Following the steps to reproduce given in the original report on both the given URL and the given testcase: http://babelfish.altavista.com/ http://www.darkpact.com/test1.html Anoakie: does it still crash for you with the very latest build? Also, if you get a chance, does it crash on any other box besides the one you reported it on? Thanks -
I'm visiting some friends right now and I was able to reproduce the bug on thier computer, running debian sid. I installed the nightly (2002-03-23) and I was able to reproduce the crash. They are running KDE 2.2.2... Maybe it's a bug with one of the debian libraries. Unfortunately, it still crashes on the latest build, and I have just reproduced it with KDE 2.2.2. If I come across any other boxes, I'll try to reproduce it again... It may be something related to debian... Maybe I should submit this to the Debian Bug Tracking System and tell them not to forward it upstream :) Your input is appreciated. What do you think I should do? Thanks
cc'ing timeless, Boris, Pav: do any of you know someone with Debian Linux? Could we cc them on this bug in order to get a debug stack trace? Thanks -
Also cc'ing jkeiser -
Created attachment 78087 [details] Backtrace with debug enabled build Backtrace from mozilla .99 compiled source with debug enabled.
Confirming based on stack trace, which shows an infinite loop involving these three calls: #3182 0x41bdb954 in nsTextFrame::PeekOffset (this=0x86222d4, aPresContext=0x85cb260, aPos=0xbfffdc20) at nsTextFrame.cpp:4253 #3183 0x41b41a66 in nsFrame::PeekOffset (this=0x86222a8, aPresContext=0x85cb260, aPos=0xbfffdc20) at nsFrame.cpp:3404 #3184 0x41b0fa1a in BRFrame::PeekOffset (this=0x86222a8, aPresContext=0x85cb260, aPos=0xbfffdc20) at nsBRFrame.cpp:266 These files are all from Layout, so reassigning to that component. Based on lxr & bonsai, cc'ing mjudge, who may be able to help - Note I have been unable to reproduce this on Red Hat; perhaps the bug is confined to Debian Linux - ?
Assignee: rods → attinasi
Status: UNCONFIRMED → NEW
Component: HTML Form Controls → Layout
Ever confirmed: true
QA Contact: madhur → petersen
16 years ago
Setting Priority to P2
Priority: -- → P2
Fixed is Mozilla 1.0.
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
Seems fine on WinXP trunk 20020614 too, though I don't think I was able to reproduce before.
You need to log in before you can comment on or make changes to this bug.