Closed
Bug 256927
Opened 20 years ago
Closed 20 years ago
|/dcc-send someNickname| crashes Mozilla
Categories
(Other Applications :: ChatZilla, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: jjfoerch, Assigned: rginda)
Details
(Keywords: crash)
Attachments
(2 files, 1 obsolete file)
4.60 KB,
text/plain
|
Details | |
1.61 KB,
patch
|
bugzilla-mozilla-20000923
:
review+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040616
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040616
Running ChatZilla 0.9.64f under Linux. The command |/dcc-send somebody| causes
Mozilla to crash. Note I did not include a file name. The filename parameter
should either be required, or cause a prompt if missing.
Reproducible: Always
Steps to Reproduce:
1. /dcc-send IRCMonkey
2.
3.
Actual Results:
Mozilla closed.
Expected Results:
Software should either prompt for a filename for warn about a missing parameter.
Reporter | ||
Comment 1•20 years ago
|
||
The source of the crash seems to be in function pickerOpen() in file-utils.js.
The crash is reproducible from ChatZilla's client tab, with this sequence of
commands:
picker = futils.getPicker (null,null,{})
picker.init (window, futils.MSG_OPEN,Components.interfaces.nsIFilePicker.modeOpen)
picker.show()
Hope this helps!
Comment 2•20 years ago
|
||
(In reply to comment #0)
> Mozilla to crash. Note I did not include a file name. The filename parameter
> should either be required, or cause a prompt if missing.
It does prompt if there's no filename - it's most likely the *picker* that's
crashing, either due to bugs in it and/or changes it how it likes to be called
from code. :)
Reporter | ||
Comment 3•20 years ago
|
||
I turned on debug messages and inserted a line into function pickOpen() just
after picker.init() and just before picker.show(). Here is the output of that
dump. The reason I'm posting this is that I notice that line + file (ERROR) ?
Is that relevant to the problem? Does it possibly mean that picker.init()
failed or is that unrelated?
Can any other linux users confirm this bug? Maybe it's platform specific.
cz: >>> dcc-send nickname: boo file: null <<<
+ defaultString (string) ''
+ init (function) [native code]
+ QueryInterface (function) [native code]
+ appendFilters (function) [native code]
+ appendFilter (function) [native code]
+ defaultExtension (string) ''
+ filterIndex (number) 0
+ displayDirectory (object) null
+ file (ERROR) ?
+ fileURL (object) null
+ files (object) null
+ show (function) [native code]
+ modeOpen (number) 0
+ modeSave (number) 1
+ modeGetFolder (number) 2
+ modeOpenMultiple (number) 3
+ returnOK (number) 0
+ returnCancel (number) 1
+ returnReplace (number) 2
+ filterAll (number) 1
+ filterHTML (number) 2
+ filterText (number) 4
+ filterImages (number) 8
+ filterXML (number) 16
+ filterXUL (number) 32
+ filterApps (number) 64
*
dist/bin/run-mozilla.sh: line 423: 6900 Segmentation fault "$prog" ${1+"$@"}
Comment 4•20 years ago
|
||
Due to John's request here's output of a send with Firefox 9.64F on Mozilla/5.0
(Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040821 Firefox/0.9.1+.
+ defaultString (ERROR) ?
+ init (function) [native code]
+ QueryInterface (function) [native code]
+ appendFilters (function) [native code]
+ appendFilter (function) [native code]
+ defaultExtension (string) ”
+ filterIndex (number) 0
+ displayDirectory (object)
+ file (object) null
+ fileURL (object)
+ files (object)
+ show (function) [native code]
+ modeOpen (number) 0
+ modeSave (number) 1
+ modeGetFolder (number) 2
+ modeOpenMultiple (number) 3
+ returnOK (number) 0
+ returnCancel (number) 1
+ returnReplace (number) 2
+ filterAll (number) 1
+ filterHTML (number) 2
+ filterText (number) 4
+ filterImages (number) 8
+ filterXML (number) 16
+ filterXUL (number) 32
+ filterApps (number) 64
*
Notice the + file (object) null and the + defaultString (ERROR) ?.
Assignee: rginda → blizzard
Component: ChatZilla → GFX: Gtk
QA Contact: samuel → ian
Comment 5•20 years ago
|
||
the crash occurs at nsFileView::SetFilter (this=0xa9d24b8, aFilterString=0x0)
at nsFileView.cpp:306
306 for (chr = aFilterString; *chr; ++chr) {
(note that aFilterString is NULL)
Comment 6•20 years ago
|
||
marking NEW
> It does prompt if there's no filename - it's most likely the *picker* that's
> crashing, either due to bugs in it and/or changes it how it likes to be called
> from code. :)
I couldn't find a Mozilla build where it actually worked.
cmdDCCSend calls pickOpen without a typeList parameter, which passes it on as
null to getPicker, which does nothing with it. So the filepicker dialog is
opened without setting the type, which dies here:
http://lxr.mozilla.org/mozilla/source/xpfe/components/filepicker/res/content/filepicker.js#135
135 treeView.setFilter(filterTypes[o.filterIndex]);
(filterTypes is empty)
var pickerRv = pickOpen(MSG_DCCFILE_SEND, "$all");
is sufficient to fix the crash, although this is arguably a bug in filepicker
moving back to chatzilla...
Assignee: blizzard → rginda
Status: UNCONFIRMED → NEW
Component: GFX: Gtk → ChatZilla
Ever confirmed: true
QA Contact: ian → samuel
Comment 7•20 years ago
|
||
(In reply to comment #6)
> marking NEW
>
> > It does prompt if there's no filename - it's most likely the *picker* that's
> > crashing, either due to bugs in it and/or changes it how it likes to be called
> > from code. :)
>
> I couldn't find a Mozilla build where it actually worked.
Well, it works fine in every Mozilla build I've used since I wrote the code,
right up to "Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a3)
Gecko/20040828" which I'm using today.
> cmdDCCSend calls pickOpen without a typeList parameter, which passes it on as
> null to getPicker, which does nothing with it. So the filepicker dialog is
> opened without setting the type, which dies here:
>
http://lxr.mozilla.org/mozilla/source/xpfe/components/filepicker/res/content/filepicker.js#135
> 135 treeView.setFilter(filterTypes[o.filterIndex]);
> (filterTypes is empty)
>
> var pickerRv = pickOpen(MSG_DCCFILE_SEND, "$all");
> is sufficient to fix the crash,
I'd actually fix file-utils.js#86 to work without a typeList parameter, but it's
the same effect.
> although this is arguably a bug in filepicker
The file picker should never crash, like any other code. ChatZilla will have to
work around it, but I want to see the picker fixed too.
Comment 8•20 years ago
|
||
This works fine on OS/2 - no crash.
Comment 9•20 years ago
|
||
> Well, it works fine in every Mozilla build I've used since I wrote the code,
chatzilla from linux trunk 20040610 crashes for me.
this patch forces the "all" filter to always be included by getPicker
I filed bug 257427 to get the filepicker fixed.
Comment 10•20 years ago
|
||
Attachment #157410 -
Attachment is obsolete: true
Updated•20 years ago
|
Attachment #157411 -
Flags: review?(silver)
Comment 11•20 years ago
|
||
Comment on attachment 157411 [details] [diff] [review]
the right patch
>+
>+ if (!allIncluded) {
>+ picker.appendFilters(FILTER_ALL);
>+ }
Firstly, I'll be picky - start braces should be at the same level as the end
ones, and should be omitted entirely if there's only one line in them. See
http://www.hacksrus.com/~ginda/pedant.html
Otherwise fine. :)
r=silver@warwickcompsoc.co.uk with that change (no braces).
Attachment #157411 -
Flags: review?(silver) → review+
Comment 12•20 years ago
|
||
Checked in.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Updated•20 years ago
|
Product: Core → Other Applications
You need to log in
before you can comment on or make changes to this bug.
Description
•