Closed Bug 317000 Opened 20 years ago Closed 20 years ago

Crash (seg fault) if I try to scroll in file selection dialog/window.

Categories

(Firefox :: General, defect)

Product:
Firefox
Component:
General
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: saber850, Unassigned)

Details

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051111 Firefox/1.5 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051111 Firefox/1.5 If I try to scroll in a file selection dialog/window, Firefox 1.5 RC2 and RC3 crashes ("segmentation fault" is output in console). The file dialogs where the crashed are: - Open (File->Open) - Upload (HTML form) - Download (from web page; select a destination) The first time the file selection dialog is opened it takes a while (5-10 seconds) during which time the CPU is pinned at 100% usage. Reproducible: Always Steps to Reproduce: 1. Open browser 2. Choose 'Open' from the 'File' menu 3. Try scrolling (via mouse wheel or the scroll bar) 4. Crash immediately Actual Results: Segmentation fault. Expected Results: The file list should scroll down. I'm using Gentoo Linux. Kernel 2.6.11.11 GNOME 2.10.2 GTK+ 2.6.10 (I list this version because the file selection dialog seems to be the standard GTK one). Firefox is the binary from mozilla.org (after being automatically updated from RC2 which was automatically updated from RC1). I didn't notice this problem on Firefox 1.5 RC1, though I didn't explicitly test it. The problem is not present in Firefox 1.1.
The problem is not present in Firefox 1.0.x (small typo in the description).
Two things: can you reproduce this in other gtk applications' file picker dialogs? Also, do you think you could build debug, get symbols for gtk and get a useful stacktrace for the crash?
> Two things: can you reproduce this in other gtk applications' file picker > dialogs? I tested the file picker in gedit and it does not exhibit this problem. > Also, do you think you could build debug, get symbols for gtk and get > a useful stacktrace for the crash? I will try this.
> > Also, do you think you could build debug, get symbols for gtk and get > > a useful stacktrace for the crash? > I will try this. I'm having problems with this. I built gtk in debug but I can't get to the actual test (scroll in the file picker) while in gdb. I start gdb w/ Firefox and run. Firefox starts and the page loads. I select File->Open and nothing happens. gdb reports some threads have terminated. After waiting some time (30-60 sec) gdb prints more threads have terminated. I'll try to spend more time on it on Tue (this is happening at work).
Firefox 1.5 RC3 on my home machine (also Gentoo Linux) does not exhibit this behavior. I'll do more investigation on Tue 11/22.
Verified this w/ a new user and fresh download of RC3 binaries. So it doesn't look to be a result of older firefox preferences, an extension, or a theme. Also verified this in safe mode.
Verified this when my PATH and LD_LIBRARY_PATH env vars are set only to "." (cwd) to rule out a conflict w/ the system-installed firefox (1.0.7). I verified a simple command like 'ls' doesn't work (as it's not in the current directory), then ran ./firefox. Same problem in the file selection dialog.
Try starting Firefox with `./run-mozilla.sh -g -d gdb ./firefox-bin'. Could you have somehow messed up when building gtk with debug?
> Try starting Firefox with `./run-mozilla.sh -g -d gdb ./firefox-bin'. Thanks, this worked. Here's the output. I put a marker "<<file open here>>" to indicate where/when I opened the file dialog. Here's the output: -------------------------------------- MOZILLA_FIVE_HOME=. LD_LIBRARY_PATH=.:./plugins:.:. DISPLAY=localhost:11.0 DYLD_LIBRARY_PATH=.:. LIBRARY_PATH=.:./components:. SHLIB_PATH=.:. LIBPATH=.:. ADDON_PATH=. MOZ_PROGRAM=./firefox-bin MOZ_TOOLKIT= moz_debug=1 moz_debugger=gdb /usr/bin/gdb ./firefox-bin -x /tmp/mozargs.tZTNqS GNU gdb 6.3 <snip>GNU gdb copyright</snip> gdb> run (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread -1220568864 (LWP 32627)] [New Thread -1220883536 (LWP 32637)] [New Thread -1231684688 (LWP 32640)] [New Thread -1244574800 (LWP 32643)] [New Thread -1254421584 (LWP 32645)] [Thread -1254421584 (LWP 32645) exited] [New Thread -1262814288 (LWP 32646)] <<file open here>> Program received signal SIG33, Real-time event 33. [Switching to Thread -1262814288 (LWP 32646)] Error while running hook_stop: Invalid type combination in ordering comparison. 0xffffe410 in __kernel_vsyscall () gdb> -------------------------------------- At this point, Firefox is not responding (won't repaint). Here's the backtrace: -------------------------------------- gdb> bt #0 0xffffe410 in __kernel_vsyscall () #1 0xb7e5ebcc in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 #2 0xb7e9f18e in PR_Unlock () from ./libnspr4.so #3 0xb7e9f31a in PR_WaitCondVar () from ./libnspr4.so #4 0x080ea70c in nsTHashtable<nsBaseHashtableET<nsDepCharHashKey, nsAutoPtr<nsINIParser::INIValue> > >::~nsTHashtable () #5 0x080ea8c4 in nsTHashtable<nsBaseHashtableET<nsDepCharHashKey, nsAutoPtr<nsINIParser::INIValue> > >::~nsTHashtable () #6 0xb7ea3588 in PR_Select () from ./libnspr4.so #7 0xb7e5caba in start_thread () from /lib/tls/libpthread.so.0 #8 0xb759935e in clone () from /lib/tls/libc.so.6 gdb> -------------------------------------- > Could you have somehow messed up when building gtk with debug? Looks like it. Since Gentoo's ebuild for gtk doesn't support a 'debug' option natively, I added '--enable-debug=yes' to the econf in the src_compile function of the ebuild. This doesn't enable debugging symbols though (resulting shared objs are stripped). Any familiarity w/ Gentoo's ebuilds?
I received some assistance and built gtk+ w/ debugging symbols. Unfortunately, the behavior in the debugger is the same as I previously posted. That is, when I request the File->Open dialog (Ctrl+O in this case), gdb reports: Program received signal SIG33, Real-time event 33. [Switching to Thread -1272976464 (LWP 28004)] Error while running hook_stop: Invalid type combination in ordering comparison. 0xffffe410 in __kernel_vsyscall () From that time Firefox stops responding (even if I 'continue' in gdb until control returns to Firefox. I can't get far enough to trigger the crash in gdb to get a stack trace. Any suggestions?
handle SIG33 noprint
> handle SIG33 noprint Thanks for the suggestion. I used: handle SIG33 noprint nostop which got me to the file picker (yay). Unfortunately, I can scroll the file list without a problem (ie. browser isn't crashing). Some more testing, the browser isn't crashing when I start Firefox via "./firefox-bin" (ie. no debugger) in my fresh user account. Restarting this browser to test my own account...
In my own user account the crash is gone. But the delay when bringing up the file selection dialog for the first time (10-15 sec) is still present. I guess it's related to my build of gtk+. Thank you very much for your help; I really appreciate it. Sorry to have wasted your time.
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → INVALID
(In reply to comment #13) > In my own user account the crash is gone. But the delay when bringing up the > file selection dialog for the first time (10-15 sec) is still present. > > I guess it's related to my build of gtk+. > > Thank you very much for your help; I really appreciate it. > Sorry to have wasted your time. Thanks for the help, Nick. The bug with the Save As dialog taking a while to come up is probably bug 305970.
You need to log in before you can comment on or make changes to this bug.