Closed Bug 293885 Opened 19 years ago Closed 19 years ago

crash when using file browser from <input type="file"> to traverse directory with name of 31 or more characters

Categories

(Firefox :: General, defect)

x86
Windows Server 2003
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 234192

People

(Reporter: dpinkowitz, Unassigned)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4

Whenever I try to use the file browser generated from <input type="file"> on any
web page, if the directory I wish to search in has a name with 31 or more
characters, the browser crashes.

Reproducible: Always

Steps to Reproduce:
1.Access web page with <input type="file"> for file upload.
2.Try to pick a directory with a name containing at least 31 characters and
click on the directory name.
3.Once clicking on the directory name, the browser will crash.

Actual Results:  
The browser crashed.

Expected Results:  
It should have listed the files in that directory.

Talkback Incident Number TB5773324Y.
Incident ID: 5773324
Stack Signature	USER32.dll + 0x35210 (0x77d35210) ac4dc31c
Product ID	Firefox10
Build ID	2005051112
Trigger Time	2005-05-12 07:12:08.0
Platform	Win32
Operating System	Windows NT 5.2 build 3790
Module	USER32.dll + (00035210)
URL visited	
User Comments	
Since Last Crash	21 sec
Total Uptime	80 sec
Trigger Reason	Access violation
Source File, Line No.	N/A
Stack Trace 	
USER32.dll + 0x35210 (0x77d35210)
kernel32.dll + 0x244b (0x77e4244b)
kernel32.dll + 0x30abc (0x77e70abc)
USER32.dll + 0x351e6 (0x77d351e6)
USER32.dll + 0x351e6 (0x77d351e6)
USER32.dll + 0x351e6 (0x77d351e6)
SHELL32.dll + 0x1abd87 (0x7cf2bd87)
USER32.dll + 0x351e6 (0x77d351e6)
USER32.dll + 0x351e6 (0x77d351e6)
USER32.dll + 0x351e6 (0x77d351e6)
USER32.dll + 0x351e6 (0x77d351e6)
USER32.dll + 0x351e6 (0x77d351e6)
USER32.dll + 0x351e6 (0x77d351e6)
except_handler3
kernel32.dll + 0x30abc (0x77e70abc)

these *suck*. i thought i already stuck in a handler, in fact, i know i did:
http://bonsai.mozilla.org/cvslog.cgi?file=mozilla/widget/src/windows/nsFilePicker.cpp&rev=1.75

reporter: you're going to have to help me out a *lot*.

this means giving specific spelling including specific case (Documents and
Settings instead of "my documents" or "documents and settings"), and certainly
full paths. if you have a problem with disclosing this information, then you
should setup an account where you can reproduce the problem and the information
you'd be disclosing is not confidential.

beyond that, can you attach a zipped dwi profiling the crash? follow the steps
at http://www.mozilla.org/quality/help/dependency-walker.html

Also, if at all possible, please try using a current nightly.

As it happens. I'm 99.9999% certain this is fixed on trunk, see:
http://bonsai.mozilla.org/cvsgraph.cgi?file=mozilla/widget/src/windows/nsFilePicker.cpp
you are using 1.74.6.1.2.1

The fix is 1.75.
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → WORKSFORME
It seems to work with the latest nightly build:

Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8b2) Gecko/20050511
Firefox/1.0+

Let me know if you need the other information anymore.
if you use depends with firefox 1.0.4 we might be able to track down the faulting module which wouldn't be such a bad thing...

*** This bug has been marked as a duplicate of 234192 ***
Resolution: WORKSFORME → DUPLICATE
My DWI file is located at:

ftp://ftp.unipress.com/pub/fileBrowse.zip

I went to the following url to use the file upload browser button:

http://validator.w3.org/

My directory that causes the browser to crash is this:

D:\01234567890123456789012345678901

looks like adobe's pdfshell is the culprit (note: this is not scientific, but
for testing purposes you could try renaming pdfshell.dll to pdfshell.dul and see
if you still die)

00:00:14.610: DllMain(0x03CA0000, DLL_PROCESS_ATTACH, 0x00000000) in "c:\program
files\adobe\acrobat 7.0\activex\PDFSHELL.DLL" returned 1 (0x1) by thread 14.
00:00:14.625: LoadLibraryExW("C:\Program Files\Adobe\Acrobat
7.0\ActiveX\PDFShell.dll", 0x00000000, LOAD_WITH_ALTERED_SEARCH_PATH) returned
0x03CA0000 by thread 14.
00:00:14.656: GetProcAddress(0x03CA0000 [c:\program files\adobe\acrobat
7.0\activex\PDFSHELL.DLL], "DllGetClassObject") called from
"c:\windows\system32\OLE32.DLL" at address 0x771798BD and returned 0x03CA3D8D by
thread 14.
00:00:14.656: GetProcAddress(0x03CA0000 [c:\program files\adobe\acrobat
7.0\activex\PDFSHELL.DLL], "DllCanUnloadNow") called from
"c:\windows\system32\OLE32.DLL" at address 0x771798CF and returned 0x03CA1A24 by
thread 14.
00:00:14.656: LoadLibraryA("ole32.dll") called from "c:\program files\mozilla
firefox\components\FULLSOFT.DLL" at address 0x010B7395 by thread 14.
00:00:14.656: LoadLibraryA("ole32.dll") returned 0x77160000 by thread 14.
00:00:14.656: GetProcAddress(0x77160000 [c:\windows\system32\OLE32.DLL],
"StgOpenStorageOnHandle") called from "c:\windows\system32\SHELL32.DLL" at
address 0x7CEDFD3D and returned 0x7724E69E by thread 14.
00:00:14.672: GetProcAddress(0x77160000 [c:\windows\system32\OLE32.DLL],
"CoTaskMemAlloc") called from "c:\windows\system32\SHELL32.DLL" at address
0x7CDF7968 and returned 0x77161D41 by thread 14.
00:00:14.672: DllMain(0x03CA0000, DLL_PROCESS_DETACH, 0x00000000) in "c:\program
files\adobe\acrobat 7.0\activex\PDFSHELL.DLL" called by thread 14.
00:00:14.672: DllMain(0x03CA0000, DLL_PROCESS_DETACH, 0x00000000) in "c:\program
files\adobe\acrobat 7.0\activex\PDFSHELL.DLL" returned 1 (0x1) by thread 14.
00:00:14.672: Unloaded "c:\program files\adobe\acrobat 7.0\activex\PDFSHELL.DLL"
at address 0x03CA0000 by thread 14.
00:00:17.063: Terminating process by user's request.
00:00:17.063: Thread 1 exited with code 57005 (0xDEAD).
That did not work, but I think I may have inadvertently sent the wrong
Dependency Walker file. Try this one and look around timecode 00:00:14.625.

ftp://ftp.unipress.com/pub/fileBrowse2.zip
the only interesting bit is the webdav thing, but it's a microsoft library, and
i don't understand what it's thinking. i suppose we could try to see whether
windbg/ntsd can shed any light on what's actually failing. (if you have web
server space for a full dump....)

1. grab: debugging tools for windows @
http://www.microsoft.com/whdc/devtools/debugging/installx86.mspx
2. run windbg
3. file>symbol path
srv*c:\symbols*http://msdl.microsoft.com/download/symbols
4. file>open executable
start firefox from there, crash quickly
(wait) [windbg will grab symbols from microsoft, this isn't very fast if you've
never done it before]
6. you'll be at a > prompt. it might be a good idea to try:
> !analyze -v
the output might explain what's going on (that'd be wonderful, but probably not
very likely)
7. at the > prompt, to create a cab:
> .dump /maipwdc /u /ba /c "firefox104 bug 293885" crash
the resulting (cab) file will be fairly huge, and might be absolutely useless. 
You need to log in before you can comment on or make changes to this bug.