crash while saving an image when the window with the image is closed before saving

RESOLVED DUPLICATE of bug 235453

Status

()

RESOLVED DUPLICATE of bug 235453
14 years ago
5 years ago

People

(Reporter: chris, Assigned: bugs)

Tracking

1.7 Branch
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments)

(Reporter)

Description

14 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041112 Firefox/1.0
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041112 Firefox/1.0

When a new window (no tab) with an image I want to save is closed before I
complete the save process (clicking "Save") firefox crashes. 

Reproducible: Always
Steps to Reproduce:
1. Go to a Gallery (like www.open-server.de/~chkorn/images/images.py)
2. Choose a image and open it IN A NEW window
3. Do a right-click on the image and choose "Save Image As..."
4. Close the Window with the image via CTRL+W (closing via pressing the X
doesn't work for me)
5. Click "Save" in the Save Image window
Actual Results:  
Firefox crashes

Expected Results:  
No Crash and/or window not closable via CTRL+W (should also avoid the crash)
(Reporter)

Comment 1

14 years ago
Reported Error on exit: 
Segmentation fault

(Reporter)

Comment 2

14 years ago
another information i forget:
i have the XFCE desktop environment and i'm using it's "auto-focus" feature. 
without this feature it normally isn't possible to highlight the browserwindow
and to close it via CTRL+W. (AFAIK)
Version: unspecified → 1.0 Branch

Comment 3

14 years ago
I've been able to reproduce this, using xfce without having the autofocus
feature enabled.

Comment 4

14 years ago
is this an official mozilla.org build? if so, do you have components/talkback ?
(Reporter)

Comment 5

14 years ago
no it isn't. it's a "homemade" version from gentoo linux. 

Comment 6

14 years ago
please ask your homemaker to build with --enable-debug or
--enable-debugger-info-modules
(Reporter)

Comment 7

14 years ago
Created attachment 166039 [details]
The debug output from firefox (on enabled debug flags)
(Reporter)

Comment 8

14 years ago
Created attachment 166040 [details]
gdb's output.

ok. i now added gdb's and firefox' debugging output. 
HTH

Comment 9

14 years ago
don't forget to type |where| or |backtrace| or |bt| into gdb, so that we can
have a stack trace :).
(Reporter)

Comment 10

14 years ago
here this is the backtrace (it's also in my output file):
0xb7620046 in nanosleep () from /lib/libc.so.6

Comment 11

14 years ago
that's *one* stack frame. backtraces are generally going to have at least 10, of
which the top five will be useless.
(Reporter)

Comment 12

14 years ago
i swear this was the only output from gdb's "bt" command i got. 
i tried it at least 15 times.

or do i have to do something different than "gdb
/usr/lib/MozillaFirefox/firefox-bin PID" and typing "bt"?

Comment 13

14 years ago
i always suggest:
./firefox -g -d gdb
run
bt
(Reporter)

Comment 14

14 years ago
ahhhhhhhh ok. sorry. 

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 7804)]
0xb700b1bc in ?? ()
(gdb) bt
#0  0xb700b1bc in ?? ()
#1  0xb70d8654 in ?? ()
#2  0xbfffca8c in ?? ()
#3  0xbfffc974 in ?? ()
#4  0xb7f1d449 in XPTC_InvokeByIndex () from /usr/lib/MozillaFirefox/libxpcom.so
Previous frame identical to this frame (corrupt stack?)

Comment 15

14 years ago
Duping to similar bug 235453 .

*** This bug has been marked as a duplicate of 235453 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → DUPLICATE
Product: Firefox → Toolkit

Updated

5 years ago
Whiteboard: DUPEME
You need to log in before you can comment on or make changes to this bug.