[Bug 1000762] httpd.c crashes on javascript

[Bug 1000762] httpd.c crashes on javascript

[bugzilla-daemon]

http://bugzilla.ecoscentric.com/show_bug.cgi?id=1000762





--- Comment #5 from Jochen Gerster <Jochen.Gerster@freescale.com>  2009-05-21 13:21:58 ---
Thank you for your email.

I'm out of office and will be back in the office 8 June 2009
During this time I will have no access to my emails.
Your email isn't automatically forwarded.

In urgent case please contact Anita.Maliverney@freescale.com

Thank you and best regards
Jochen Gerster


-- 
Configure bugmail: http://bugzilla.ecoscentric.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

[Bug 1000762] httpd.c crashes on javascript

[bugzilla-daemon]

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000762


Stefan Singer <Stefan.Singer@freescale.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |Stefan.Singer@freescale.com




--- Comment #4 from Stefan Singer <Stefan.Singer@freescale.com>  2009-05-21 13:21:02 ---
(In reply to comment #3)
> (In reply to comment #0)
> > Created an attachment (id=716)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=716) [details] [details]
> > diff file to fix the problems described above
> > When using extensive javascripting the httpd.c webserver crashes, when it
> > encounters the EOF character. The attached patch just filters that out.
> > Probably not an entirely clean fix, but avoids any further crash with no
> > visible problems.
> (In reply to comment #2)
> > (In reply to comment #1)
> > > Nick, presumably JavaScript can introduce EOF chars in the TCP stream. Does the
> > > (reversed) patch make sense or is this hiding a more fundamental problem?
> > > 
> > I'm not sure what this patch is trying to do. The EOF returned from getc() is
> > actually -1, and indicates that the remote end has closed the connection. An
> > EOF character, Ctrl-D, would appear as 0x04. EOF from getc() indicates that the
> > remote end is failing to complete the HTTP protocol request, and this patch is
> > just covering that up. Just breaking out of this loop seem incorrect, since the
> > connection is now closed, and no response can be returned.
> > Admittedly this code could probably be made a little more robust in the face of 
> > dropped connections. But I don't think this patch is the right way to do that.
> Hi Nick, agreed, this is not a really clean fix, but I had the problem, that
> the webserver was always crashing with a javascript, that was polling some
> value very frequently, as soon as mouse traffic was created in addition.
> Applying this patch at least makes the httpd stable and as a user of the
> webserver there are no visible problems.

Hi Nick, also I agree this might not be the perfect clean fix, it at least
solves the user observed problem. I would think either the real root cause
should be fixed or at least this patch should be used, since it hides the
problem of the root cause. Don't you agree ?


-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

[Bug 1000762] httpd.c crashes on javascript

[bugzilla-daemon]

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000762





--- Comment #3 from Stefan Singer <Stefan.Singer@freescale.com>  2009-05-12 19:22:03 ---
(In reply to comment #0)
> Created an attachment (id=716)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=716) [details]
> diff file to fix the problems described above
> When using extensive javascripting the httpd.c webserver crashes, when it
> encounters the EOF character. The attached patch just filters that out.
> Probably not an entirely clean fix, but avoids any further crash with no
> visible problems.

(In reply to comment #2)
> (In reply to comment #1)
> > Nick, presumably JavaScript can introduce EOF chars in the TCP stream. Does the
> > (reversed) patch make sense or is this hiding a more fundamental problem?
> > 
> I'm not sure what this patch is trying to do. The EOF returned from getc() is
> actually -1, and indicates that the remote end has closed the connection. An
> EOF character, Ctrl-D, would appear as 0x04. EOF from getc() indicates that the
> remote end is failing to complete the HTTP protocol request, and this patch is
> just covering that up. Just breaking out of this loop seem incorrect, since the
> connection is now closed, and no response can be returned.
> Admittedly this code could probably be made a little more robust in the face of 
> dropped connections. But I don't think this patch is the right way to do that.


Hi Nick, agreed, this is not a really clean fix, but I had the problem, that
the webserver was always crashing with a javascript, that was polling some
value very frequently, as soon as mouse traffic was created in addition.
Applying this patch at least makes the httpd stable and as a user of the
webserver there are no visible problems.


-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

[Bug 1000762] httpd.c crashes on javascript

[bugzilla-daemon]

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000762


John Dallaway <john@dallaway.org.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|jifl@ecoscentric.com        |nickg@ecoscentric.com




--- Comment #1 from John Dallaway <john@dallaway.org.uk>  2009-05-12 17:43:25 ---
Nick, presumably JavaScript can introduce EOF chars in the TCP stream. Does the
(reversed) patch make sense or is this hiding a more fundamental problem?


-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.