[Bug 1000762] New: httpd.c crashes on javascript

[Bug 1000762] New: httpd.c crashes on javascript

[bugzilla-daemon]

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

           Summary: httpd.c crashes on javascript
           Product: eCos
           Version: 3.0
          Platform: All
        OS/Version: All
            Status: UNCONFIRMED
          Severity: normal
          Priority: normal
         Component: Other
        AssignedTo: jifl@ecoscentric.com
        ReportedBy: Stefan.Singer@freescale.com
         QAContact: ecos-bugs@ecos.sourceware.org
                CC: Jochen.Gerster@freescale.com
             Class: ---


Created an attachment (id=716)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=716)
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.


-- 
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.

[Issue 1000762] httpd.c crashes on javascript

[bugzilla-daemon]

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





--- Comment #2 from Nick Garnett <nickg@ecoscentric.com>  2009-05-12 18:09:40 ---
(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.


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

[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


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.