public inbox for ecos-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug 1000762] New: httpd.c crashes on javascript
@ 2009-05-12 12:27 bugzilla-daemon
2009-05-12 16:43 ` [Bug 1000762] " bugzilla-daemon
` (3 more replies)
0 siblings, 4 replies; 5+ messages in thread
From: bugzilla-daemon @ 2009-05-12 12:27 UTC (permalink / raw)
To: ecos-bugs
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug 1000762] httpd.c crashes on javascript
2009-05-12 12:27 [Bug 1000762] New: httpd.c crashes on javascript bugzilla-daemon
@ 2009-05-12 16:43 ` bugzilla-daemon
2009-05-12 17:09 ` [Issue " bugzilla-daemon
` (2 subsequent siblings)
3 siblings, 0 replies; 5+ messages in thread
From: bugzilla-daemon @ 2009-05-12 16:43 UTC (permalink / raw)
To: ecos-bugs
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Issue 1000762] httpd.c crashes on javascript
2009-05-12 12:27 [Bug 1000762] New: httpd.c crashes on javascript bugzilla-daemon
2009-05-12 16:43 ` [Bug 1000762] " bugzilla-daemon
@ 2009-05-12 17:09 ` bugzilla-daemon
2009-05-12 18:22 ` [Bug " bugzilla-daemon
2009-05-21 12:21 ` bugzilla-daemon
3 siblings, 0 replies; 5+ messages in thread
From: bugzilla-daemon @ 2009-05-12 17:09 UTC (permalink / raw)
To: ecos-bugs
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug 1000762] httpd.c crashes on javascript
2009-05-12 12:27 [Bug 1000762] New: httpd.c crashes on javascript bugzilla-daemon
2009-05-12 16:43 ` [Bug 1000762] " bugzilla-daemon
2009-05-12 17:09 ` [Issue " bugzilla-daemon
@ 2009-05-12 18:22 ` bugzilla-daemon
2009-05-21 12:21 ` bugzilla-daemon
3 siblings, 0 replies; 5+ messages in thread
From: bugzilla-daemon @ 2009-05-12 18:22 UTC (permalink / raw)
To: ecos-bugs
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug 1000762] httpd.c crashes on javascript
2009-05-12 12:27 [Bug 1000762] New: httpd.c crashes on javascript bugzilla-daemon
` (2 preceding siblings ...)
2009-05-12 18:22 ` [Bug " bugzilla-daemon
@ 2009-05-21 12:21 ` bugzilla-daemon
3 siblings, 0 replies; 5+ messages in thread
From: bugzilla-daemon @ 2009-05-21 12:21 UTC (permalink / raw)
To: ecos-bugs
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2009-05-21 12:21 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-05-12 12:27 [Bug 1000762] New: httpd.c crashes on javascript bugzilla-daemon
2009-05-12 16:43 ` [Bug 1000762] " bugzilla-daemon
2009-05-12 17:09 ` [Issue " bugzilla-daemon
2009-05-12 18:22 ` [Bug " bugzilla-daemon
2009-05-21 12:21 ` bugzilla-daemon
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).