This is the mail archive of the ecos-bugs@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug 1000762] httpd.c crashes on javascript


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]