Browser crash on this url (maybe related to strange proxy setting)



Core Graveyard
Security: UI
17 years ago
2 years ago


(Reporter: Guillaume Coté, Assigned: Stephane Saux)



Other Branch
Windows 95

Firefox Tracking Flags

(Not tracked)





17 years ago
Step to reproduce the bug :

Open mozilla
Type the url
Hit return

Version 0.9.3
Buildid : 2001080110

As I mention in the bug description, the bug may be related to my strange proxy 
setting.  I have 3 crash related to this bug, but Talkback can't pass througth 
my proxy.  If there is a way to take talkback report and attach them directly 
to the bug, let me know.  If not, I'll try to use that config file as describe 
in bug 19271.

Regarding my proxy setting, I have one set for the http and one for the sock.  
What I am using is actualy a proxy that connect to another proxy.  The other 
line of the manual proxy setting dialog are blank.

I know I don't provide you a lot of information on that, but I am willing to do 
test.  If somebody else could try to access the same url with the same build 
without a proxy (and with another) to make sure my proxy setting are invole in 
the bug, I would appreciate.


17 years ago
Keywords: crash

Comment 1

17 years ago
Reporter: The URL loads "fine" (it doesn't crash) but is a 404 page. If I recall
corectly, when Moz crashes and Talkback pops up, it creates a talkback.ini file
which contains the needed info. When Talkback pops up, just ignore it for a
moment and search for that. If you find it, attach it. Better than nothing. :)

Comment 2

17 years ago
Sorry, I made a mistake typing the URL, it's a https, not a http.

Comment 3

17 years ago
Any https access on seem to reproduce the bug.  I also try https on 
another site ( and it reproduce the bug.

Regarding talkback, the talkback.ini contains the following :

HistorySettings = 3, 10, 100
SeenIntro = 1
EmailEdit = ""
URLEdit = ""
LocalKey = 82A55A7A46
MainWindowTop = 23
MainWindowLeft = 22
MainWindowWidth = 803
MainWindowHeight = 571
ColumnWidths = 80, 90, 115, 150
RandomPool = 

I don't it's very usefull, but there is also file with the .pak extension, in 
the same number that the number of crash I had with mozilla.  If I attach those 
file, can someone read them?

Comment 4

17 years ago
Grey and Guillaume, thanks for your help in testing Mozilla.  The talkback data
actually isn't useful until it has been sent into a server where I can extract a
stack trace. Please go to your Mozilla install directory, look for a components/
directory.  In there you should see a program called talkbacl.exe.  Doubleclick
on that application and it will launch the Talkback executable.  If you already
sent in the report and the send was successful you should see one (or more)
talkback Incidents listed in the Talkback window.  If you see that please
comment the Incident ID to this bug. If you don't see that please try to
reproduce the crash again and make sure to send in the data when the talkback
wizard pops up.  You can run talkback.exe again and it should have an Incident
ID.  Thanks.

Comment 5

17 years ago
Incident id that I think are related to this bug : 


Also, the bug seem to happer on any https I try.  Anybody has a list of https 
that I could try.

Comment 6

17 years ago
looks like PSM to me. 

Incident ID 34229974
Stack Signature nsHashtable::Exists 68fe52d9
Bug ID
Trigger Time 2001-08-17 07:19:17
Email Address
User Comments Type this url in the location bar and hit return see bug 94523
Build ID 2001080112
Product ID MozillaTrunk
Platform ID Win32
Trigger Reason Access violation
Stack Trace
nsHashtable::Exists [d:\builds\seamonkey\mozilla\xpcom\ds\nsHashtable.cpp, line 261]
[d:\builds\seamonkey\mozilla\security\manager\ssl\src\nsNSSIOLayer.cpp, line 1802]
[d:\builds\seamonkey\mozilla\security\manager\ssl\src\nsNSSIOLayer.cpp, line 1881]
line 74]
[d:\builds\seamonkey\mozilla\netwerk\base\src\nsSocketTransport.cpp, line 737] 
Assignee: asa → ssaux
Component: Browser-General → Client Library
Ever confirmed: true
Product: Browser → PSM
QA Contact: doronr → ckritzer
Version: other → unspecified

Comment 7

17 years ago
reporter, can you try a more recent build?
Using win32 Build ID 2001082803 and a proxy server I'm able to connect without a
Marking as worksforme.
Reopen is necessary.
Last Resolved: 17 years ago
Resolution: --- → WORKSFORME

Comment 8

17 years ago
Tested build 2001082803

Confirmed worksforme


14 years ago
Component: Security: UI → Security: UI
Product: PSM → Core
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.