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)
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
Reporter | ||
Comment 2•19 years ago
|
||
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
Reporter | ||
Comment 4•19 years ago
|
||
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).
Reporter | ||
Comment 6•19 years ago
|
||
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.
Description
•