If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Problem with FF2.0/Apache Communications Causing Apache to Lock/Crash

VERIFIED WORKSFORME

Status

()

Firefox
General
--
critical
VERIFIED WORKSFORME
11 years ago
10 years ago

People

(Reporter: Larry Adams, Unassigned)

Tracking

2.0 Branch
x86
Windows XP
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Reporter)

Description

11 years ago
User-Agent:       Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; InfoPath.1; .NET CLR 2.0.50727)
Build Identifier: Firefox 2.0 (Sorry, Il'll Edit When I get back to my PC)

Hi All, 

I am a developer for The Cacti Group (www.cacti.net) and I have recently upgraded to FF2 and unfortunately discovered an error in communications between Apache 2.x and Firefox 2.0 while rendering graphics behind the scenes that causes a) The page to only partially load 2) Stuck process in Apache (aka Hung Server) 3) libpng error in Apache log. 

This problem is 100% repeatable. It occur's in Windows Firefox and Windows Apache 2.x on the same system (my test box). I would like some guidance as to how to help the Firefox team understand what is happening as this is a bad thing. I don't want FF2 locking up Apache servers out there. 

If someone can please provide guidance, I will follow your instructions. Whether its installing an non-stripped version of FF2, or turning on DEBUG somehow, I am at your disposal. 

Regards, 

TheWitness 
Developer 
The Cacti Group


Reproducible: Sometimes

Steps to Reproduce:
1. Goto Cacti Web Site
2. Goto Graph Management
3. Edit Advanced Ping Graph
4. Turn on Graph Debug
5. Refresh Page Several Time

Actual Results:  
Sometimes, the page refreshes just fine, but within 6-7 attempts to refresh the page, it fails to load 100% and the Apache Server hangs.  In the Apache log there is a libpng error.  I can not reproduce this problem in Internut Exploiter (v7.0).

Expected Results:  
The page should always return successfully

I am available to work with a FF developer to isolate, but need your assistance as setting up test environment.

Comment 1

11 years ago
Really not sure what's going on here... it sounds like a problem with Apache, though. Maybe you can report it to them?
(Reporter)

Comment 2

11 years ago
I thought that as well, but for some reason I can't reproduce using any other browser, so that has to be something wrong with the request being sent to the server.  I guess I could "sniff" the post with Ethereal/Wireshark using the two browsers and sift through the rubble.  If there are any better ways to get to the bottom of this, let me know.

Larry
Create a simplified testcase. Perhaps only the special png file is needed to refresh. Then try to sniff the communication. It should be easier.

Does the same problem occurs if the apache server is running on another host and not the same machine?
(Reporter)

Comment 4

11 years ago
I will have to check.  I know that there are two backend call's on the page to the same RRDfile both generating the same graphic.  The one that fails in random.  So, it may be due to FF forking each of the processes in parallel (aka with multiple client threads) and maybe causing Apache to loose it's mind or FF closing the wrong file descriptor/socket something.

In this case, Cacti generates a page that 1) Sends a request to Apache that returns binary data (image) in one case, and forks the same call to the backend,  but in the second case return's a simple status string, typically the STDOUT from the RRDtool command.

Again, it does not happen in IE7.  I'll start to dig in sometime today.
(Reporter)

Comment 5

11 years ago
I have confirmed that the apache hanges from both Local/Local (Browser/Server) and Remove/Local (Browser/Server).  I attempt to append the sniffer captures (Wireshark format).  They are:

Ie7.0 - works all the time
ff2.0 - working 1 time
ff2.0 - working 1 time, followed by hanging server

Hmm. I don't see where to post gzip files.  Where can I send them?
(In reply to comment #5)
> Hmm. I don't see where to post gzip files.  Where can I send them?

You can add this as attachment to this bug. Simply hit "Create a New Attachment" and attach your gzip file. 

(Reporter)

Comment 7

11 years ago
Created attachment 248136 [details]
This is FF2 working As Expected

Here are the three captures that I performed.  I was unable to lock up Apache with IE7, but Apache went bonkers with FF2.  It looks like it may have to do with the version of HTML.  Looks like Apache may not fully support it or something.

There are three files.  Two that had not issues, and the third showing the lockup.  You will see that the browser sends the request and never receives a response from the server.  Apache just hands.
(Reporter)

Comment 8

11 years ago
Created attachment 248137 [details]
This is IE7 Working as Expected

Again, IE never locks up Apache.
(Reporter)

Comment 9

11 years ago
Created attachment 248138 [details]
Here is FF2 Locking Up Apache
(Reporter)

Updated

11 years ago
Attachment #248136 - Attachment description: This is FF working As Expected → This is FF2 working As Expected

Comment 10

11 years ago
for the record: any input firefox can give to a web server is input that the webserver *must* accept. not from an RFC clean perspective, but from a security perspective. If firefox can be buggy then someone can emulate the perceived behavior in order to attack you server. whether or not firefox /should/ do whatever it does may be an open question which we may investigate, but you need to fix your server.
(Reporter)

Comment 11

11 years ago
Yea, I am thinking that I need to open a ticket with the Apache Foundation as well.  Not this week though...  Do you guys support xreferencing each others bug ID's?  This may only be a Windows server issue as well.  Maybe something in the bowels of the Apache code.

TheWitness
(In reply to comment #11)
> bug ID's?  This may only be a Windows server issue as well.  Maybe something in
> the bowels of the Apache code.

To your initial comment. Can you clearly describe the steps how to reproduce it with the newest Cacti version? I cannot find your step 3 "Edit Advanced Ping Graph".
(Reporter)

Comment 13

11 years ago
Ok, lets make some assumption:

1) Windows Apache
2) Windows Cacit
3) Install Graph Template "advanced ping template" located here: http://forums.cacti.net/viewtopic.php?t=10049
4) From the consoled "Import Template".  You need to import the XML and then place the script in the scripts directory
5) Add the Advanced Ping to a Host, and Create a Graph
6) Wait for the poller to run and create the RRD file.
7) Goto "Graph Management" and View the Graph, make sure it shows.
8) Press the Graph Debug Link in the Top Right of the Page to show the graph logic and output.
9) Now, refresh the page several times as it.  It will eventually hang the server.
Is this still an issue? I ask the reporter to get more information but haven't got an answer to my latest questions. I'm not able to setup cacti and run this test. If it is still an problem use a net sniffer and record the send/received data. That would help to identify what's going on here. I also think that's a problem of Apache. 
(Reporter)

Comment 15

10 years ago
You can close this ticket.  The issue was a server issue related to out of band data interfering with in band data.  Sorry for not informing you sooner.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → WORKSFORME
Status: RESOLVED → VERIFIED
Version: unspecified → 2.0 Branch
You need to log in before you can comment on or make changes to this bug.