| Summary: | Submission Jobs: XML Parsing Error because of strange characters | ||
|---|---|---|---|
| Product: | Red Hat Enterprise MRG | Reporter: | Jan Sarenik <jsarenik> |
| Component: | cumin | Assignee: | Trevor McKay <tmckay> |
| Status: | CLOSED DUPLICATE | QA Contact: | MRG Quality Engineering <mrgqe-bugs> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 2.0 | CC: | croberts, eallen, jross, matt, tmckay |
| Target Milestone: | 2.1 | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2011-06-06 08:15:29 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
|
Description
Jan Sarenik
2011-05-26 10:18:05 UTC
Don't seem to be able to reproduce. And the special characters shouldn't matter in this case, I think, because this should just be a job listing within a submission, the jobs' args parameters won't be visible until drilling into a job. ?? At character 538 in the above paste (use vi, :goto 538) we have an <a> tag ended with no textual representation of the job for the link, that is we have "></a>" Question: why is the job name blank? And, is it really blank, or is it an unprintable character? The xml parser may not like a blank, or it may be objecting to some other characters there. I will take a look at where job names are generated and see what I can find. More strangeness. If I select that portion of text and paste into vi, it shows like this: job.job_id=4.10">〈 a></ Bad character? Going on this theory....
Paste in Vi, save. The 226 140 169 preceding 97 ("a") is clearly suspicious.
[tmckay@tmckaylt trunk]$ od -t u1 foo
0000000 106 111 98 46 106 111 98 95 105 100 61 52 46 49 48 34
0000020 62 226 140 169 97 62 60 47 10
0000031
[tmckay@tmckaylt trunk]$ od -a foo
0000000 j o b . j o b _ i d = 4 . 1 0 "
0000020 > b ff ) a > < / nl
0000031
(In reply to comment #4)
> More strangeness.
>
> If I select that portion of text and paste into vi, it shows like this:
>
> job.job_id=4.10">〈 a></
>
> Bad character?
Well, it seems impossible to know what was originally contained there but it was almost certainly an unprintable character. Was able to create the same error message by breaking during rendering and forcing unprintable characters into the link label text. Looks like we need a filter for printable characters somewhere (everywhere?) Jan, it would be interesting to know what this record looks like in the database, or maybe in qpid-tool. If you can reproduce and let me log into a machine where it is happening, I can take a look. Meanwhile I think about printable character filters -- maybe at the top level render routine where we output strings to the html page. Although, one wonders what the effect would be of checking every character output. Actually I found that the special job is not needed, I reproduced the XML parsing error with normal job which worked in previous versions. May the IE8 fixes have affected it? The repeated behavior I see is exactly following:
1. After clicking on a particular submission, I get the page
with two tabs: Jobs and Details. Current tab is Jobs and
all I can see is "Loading..." (despite I wait half a minute)
2. When I refresh the same page, I get the XML parsing error.
I am able to reproduce XML Parsing Error on a clean RHEL5 x86_64 Beaker
machine. On the RHEL5 i386 and RHEL6 both archs, I see merely empty
strings ("") instead of Job Ids in the jobs list (after clicking on
a particular submission).
Reproducibility on RHEL5 x86_64 is 100%
Above was on cumin-0.1.4767-1.el5. With cumin-0.1.4794-1.el5 I can not reproduce the parsing error even on RHEL5 x86_64. But I still see the empty string like on the other archs. Previous comment is not completely valid. I am getting the same XML Parsing Error also on cumin-0.1.4794-1.el5 But not after the upgrade of Condor. I think this bug was the same as bug 708435, for everything seems to be working now. Closing. *** This bug has been marked as a duplicate of bug 708435 *** If you want to implement the idea of modifying higher level rendering routine not to output any unprintable characters, you are free to bring this bug back to life. I just wanted to make sure the original symptoms are already gone. |