please install talkback and provide a talkback incident id.
(In reply to comment #1) > please install talkback and provide a talkback incident id. Sorry about that. Incident ID: 8588033 Link: http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=8588033 This is my original submission, and the details in the 'User Comments' aren't completely correct (did alot more investigating before I submitted this bug, after that incident was submitted).
Stack from comment 2: nsSocketTransport::Release [c:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.2_Depend/mozilla/netwerk/base/src/nsSocketTransport2.cpp, line 1479] nsHttpConnection::Activate [c:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.2_Depend/mozilla/netwerk/protocol/http/src/nsHttpConnection.cpp, line 130] nsHttpConnectionMgr::DispatchTransaction [c:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.2_Depend/mozilla/netwerk/protocol/http/src/nsHttpConnectionMgr.cpp, line 569] nsHttpConnectionMgr::ProcessNewTransaction [c:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.2_Depend/mozilla/netwerk/protocol/http/src/nsHttpConnectionMgr.cpp, line 698] nsHttpConnectionMgr::OnMsgNewTransaction [c:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.2_Depend/mozilla/netwerk/protocol/http/src/nsHttpConnectionMgr.cpp, line 726] Is this also an issue with the current nightly trunk build? http://mozilla.isc.org/pub/mozilla.org/firefox/nightly/latest-trunk/
Summary: Crash with XUL Sockets → Crash with XUL Sockets [@ nsSocketTransport::Release]
(In reply to comment #3) > Is this also an issue with the current nightly trunk build? > http://mozilla.isc.org/pub/mozilla.org/firefox/nightly/latest-trunk/ The latest nightly build is not even able to make the connection. The following errors are returned (via alert windows): 'Exception while opening socket:TypeError: this.TransportService.init is not a function' 'Unable to write in stream socket: TypeError: this.outputStream has no properties' 'Error while reading socket: [Exception... "Component returned failure code: 0xc1f30001 (NS_ERROR_NOT_INITIALIZED) [nsIScriptableInputStream.available]" nsresult: "0xc1f30001 (NS_ERROR_NOT_INITIALIZED)" location: "JS frame :: http://localhost/sockets.html :: anonymous :: line183" data: no]' 'null' There was not a crash the first time I tried this. After trying it again (in order to write out the above alert windows) Deer Park Alpha 2 Crashes with the same return: Unhandeled exception in firefox.exe: 0xC0000005: Access Violation. Incident ID: 8611852 Link: http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=8611852
Assignee: nobody → darin
Component: General → Networking: HTTP
Product: Firefox → Core
QA Contact: general → networking.http
Version: unspecified → 1.7 Branch
13 years ago
Component: Networking: HTTP → Networking
QA Contact: networking.http → benc
Summary: Crash with XUL Sockets [@ nsSocketTransport::Release] → Crash with sockets [@ nsSocketTransport::Release]
this.transportService = Components.classes["@mozilla.org/network/socket-transport-service;1"].createInstance(Components.interfaces.nsISocketTransportService); it's a service - you must use getService, not createInstance! does it work with that change?
Created attachment 193545 [details] testcase This is more or less copied from the reporter. The error in comment 4 happens because of the fix for bug 283049. Removing this.transportService.init(); makes it work again. The testcase needs to be opened locally. It crashes for me on reload. Talkback ID: TB8631327X The suggestion in comment 5 works and makes the testcase not crash on reload.
(Sorry for delayed reply) After changing to getService as reccommended in comment #5, the script did function without a crash (Firefox 1.0.6), but it did not run without issues. After running the said script, Firefox starts exibiting a odd behavior in which it refuses to load any pages. Any links (Bookmarks, Refresh/Home Buttons, anything) do not actually change the page; it stays. Very odd behavior. With the latest nightly trunk: The same errors are returned as outlined in comment #4, but no longer crashes (thankfully). Hopefully this can be sorted out before FF 1.5 B1
Oops. I kind of completely ignored comment #6, sorry. My mistake. With the changes specified in comment #6 (removing this.transportService.init();), it works in the latest trunk. Although FF 1.0.6 still exhibits the odd behavior as described in comment #7, I think I can live with it until 1.5 Everything seems to be working perfectly. Sorry for the mix-up. Although, it would be nice if using createInstance simply returned a error instead of crashing. Would be nice to have that sorted. Thanks for your time.
you should also remove the .shutdown call, that probably fixes the 1.0.x issues. in lzSocket.js: this._connected==false; I think you mean =, not == What's the purpose of your wait() function if you have a blocking input stream?
Not a bug; just misuse of a contract.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → INVALID
But should the misuse of a contract cause a crash then? Shouldn't you get an error message or something like that, instead?
There's no way to detect it, really.
actually we can fix the generic cosntructor macros to cause this not to mess up.
Yeah, that's true. Patches welcome.
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
Confirming per comment 13 and comment 14, since there's something that can be patched here.
Status: UNCONFIRMED → NEW
Ever confirmed: true
The generic constructor macros are xpcom, not networking...
Component: Networking → XPCOM
QA Contact: networking → xpcom
(I tested this on latest-trunk mozilla-central nightly build on WinXP SP3) Turning security-sensitive just-in-case, due to !exploitable PROBABLY_EXPLOITABLE result. 0:019> !exploitable -v HostMachine\HostUser Executing Processor Architecture is x86 Debuggee is in User Mode Debuggee is a live user mode debugging session on the local machine Event Type: Exception *** WARNING: Unable to verify checksum for C:\Documents and Settings\Administrator\Desktop\firefox\nspr4.dll *** WARNING: Unable to verify checksum for C:\Documents and Settings\Administrator\Desktop\firefox\xul.dll Exception Faulting Address: 0x10 First Chance Exception Type: STATUS_ACCESS_VIOLATION (0xC0000005) Exception Sub-Type: Write Access Violation Exception Hash (Major/Minor): 0xb270241.0x1b4d665e Stack Trace: ntdll!RtlpWaitForCriticalSection+0x8c ntdll!RtlEnterCriticalSection+0x46 nspr4!PR_Lock+0x17 xul!nsSocketTransportService::Dispatch+0x24 xul!nsAStreamCopier::PostContinuationEvent_Locked+0x1e xul!nsAStreamCopier::OnOutputStreamReady+0x19 xul!nsSocketOutputStream::OnSocketReady+0x84 xul!nsSocketTransport::OnSocketDetached+0x62 xul!nsSocketTransportService::DetachSocket+0x24 xul!nsSocketTransportService::DoPollIteration+0x226 xul!nsSocketTransportService::OnProcessNextEvent+0x16 xul!nsThread::ProcessNextEvent+0x32e xul!NS_ProcessPendingEvents_P+0x29 xul!nsSocketTransportService::Run+0x7c xul!nsThread::ProcessNextEvent+0x213 xul!NS_ProcessNextEvent_P+0x1b xul!nsThread::ThreadFunc+0x6c nspr4!_PR_NativeRunThread+0xdb nspr4!pr_root+0xd MOZCRT19!_callthreadstartex+0x48 MOZCRT19!_threadstartex+0x66 kernel32!BaseThreadStart+0x37 Instruction Address: 0x355c57 Description: User Mode Write AV near NULL Short Description: WriteAV Exploitability Classification: PROBABLY_EXPLOITABLE Recommended Bug Title: Probably Exploitable - User Mode Write AV near NULL starting at nspr4!PR_Lock+0x17 (Hash=0xb270241.0x1b4d665e) User mode write access violations that are near NULL are probably exploitable.
Note that this bug requires the calling JS to have system privileges. If that's the case, then you don't need to exploit this crash; you can just do whatever you want directly. So I don't think this should be security-sensitive, or have an sg: annotation. I also still think this bug should either be wontfix or a duplicate of the general "make it impossible to createInstance services" bug we have lying around somewhere.
And this certainly doesn't need to block any releases, imo.
(In reply to comment #18) > So I don't think this should be security-sensitive, or have an sg: annotation. Whether this is exploitable or not, we need somehow to distinguish "crashes we've evaluated for security risk" from "crashes we have not". If you think it's not exploitable it should at least have "[sg:nse]" ("Not a Security Exploit") so we can track the fact that we've looked at this. > [this should be] a duplicate of the general "make it impossible > to createInstance services" bug we have lying around somewhere. That sounds reasonable. I couldn't find that bug so I'll leave this for now.
Whiteboard: [sg:critical?] → [sg:nse] privileged code misusing components
As per comment 19, not blocking.
Flags: blocking1.9.1? → blocking1.9.1-
I think bug 336927 and bug 494946 cover the "make it impossible to createInstance services" issue, although bz might have had another bug report in mind.
Status: NEW → RESOLVED
Last Resolved: 13 years ago → 9 years ago
Resolution: --- → WONTFIX
Crash Signature: [@ nsSocketTransport::Release]
You need to log in before you can comment on or make changes to this bug.