Issue: Update to Chrome 132 causes application to hang with error Start tag expected, '<' not found

[Justin Besmano]

Hi all, 

Although we have already opened a Chromium issue case about this, we are posting here to increase visibility and also to seek for potential solution that might help to resolve our issue - Update to Chrome 132 causes application to hang with error Start tag expected, '<' not found [391499612] - Chromium

We found this problem after updating to Chrome v132. We must search for an item in our application in order to reproduce the problem, and then an error message stating that "Start tag expected, '<' not found'" appears. However, the issue happens intermittently and occurs after a random number of searches. Additionally, we have examined our XML outputs and found no syntax mistakes that correspond to the browser's error message.

Application processes:

 1. Search for an item

 2. Once Go is click, the web application will process a request that generates an XML in the backend to retrieve the information of the item.

 3. Once the XML file is generated, our web application will read the XML file in the backend using Java.

4. Once the web application reads the XML file in the backend, it’s returned as a response with the proper XML header in the URL

then, the Console shows “Start tag expected, ‘<’ not found” error and it’s pointing to the URL in step 5. This is the reason why our web application stops.

2

[Philipp Hancke]

if you can reproduce, pinpointing the change using

  https://www.chromium.org/developers/bisect-builds-py/

typically speeds up the triage tremendously (as every change has an author)

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/f7dc1625-865e-42a1-8440-35dfd7c95777n%40chromium.org.

[Justin Besmano]

Hi all, 

Our team was able to run bisect-builds.py and used these arguments -g 131.0.6778.241 -b 132.0.6834.84. here are the change logs from our runs. 

https://chromium.googlesource.com/chromium/src/+log/bb647b6582f05d9d19242402e25b9de76c882a46..6a3b6ecd7586bed966cfba158f4107e0f2cd8f48

https://chromium.googlesource.com/chromium/src/+log/eba2ee0d636c7965ae5737adde4ce5ed921fe823..65a7e88c80c90dee1ea3e1b773aa2e050c2d618f

Note: Since our issue happens INTERMITTENTLY, we also tried running bisect module a couple of times. 

The change logs that follow are tests to see if we can obtain consistent results. The logs, however, contain more items.

https://chromium.googlesource.com/chromium/src/+log/9a3704ed21bb075f315d429c582bdb1f36e120f2..a83fdac010fbf61d2680cbb9cb0b6dfcd0c13530

https://chromium.googlesource.com/chromium/src/+log/1615e690b08cf23247167888aa016a908f37a17c..08735a8c2b7c7c08d5e0dae5445358c1542685c1

Are there any significant data from our output files that might result to the start tag error that we are experiencing? 

Appreciate the help. Thank you!

[Justin Besmano]

Hi Philipp, thank you for the input regarding bisect-build.py. program - our team is currently checking on it now.

Furthermore, our team is concerned that this issue is affecting thousands of users across multiple organizations.

Team is asking if there is a possibility to set up a call with chrome-dev/Chrome support to discuss this matter? 

Thank you! 

On Tuesday, January 28, 2025 at 6:16:35 AM UTC+8 Philipp Hancke wrote:

[Khristine Belandres]

Hello Phillip, we are trying to determine what in 132 version of Chrome caused this strange behavior that we are encountering as this will help us know what to change. So if anyone knows any change in 132 that could have affected behavior given the description of issue provided above, that would be extremely helpful.

On Tuesday, January 28, 2025 at 6:16:35 AM UTC+8 Philipp Hancke wrote:

[Jayson Adams]

then, the Console shows “Start tag expected, ‘<’ not found” error and it’s pointing to the URL in step 5. This is the reason why our web application stops.

This error message appears in libxml. It looks like this is the cl that updated libxml for M132:

5836178: Roll libxml from df40f64e to 55ddccb6 | https://chromium-review.googlesource.com/c/chromium/src/+/5836178

I'm guessing the M132 update of libxml has a bug. libxml was updated again for M133 with this cl:

6097175: Roll libxml from 55ddccb6 to 169857ad | https://chromium-review.googlesource.com/c/chromium/src/+/6097175

The bug might be fixed - you might try seeing if you can repro in beta M133 or stable M133 which should ship in a few days.

Best,

__jayson

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/16919ad8-444a-4947-bd2d-ab72ffa1c525n%40chromium.org.

[Philipp Hancke]

that doesn't have any "smoking gun" and the bisects vary widely in date - if the reproduction is intermittent "taking a wrong turn" is easy sadly.

The libxml update suggested by Jayson Adams looks like a likely culprit, you'd bisect along the lines of

  python bisect-builds.py -a linux64 -g 1368540 -b 1368550 --verify-range --use-local-cache

(the commit position is 1368545 from the commit message)

That range is narrow enough that running bisect many times shouldn't take too much time.

[Justin Besmano]

Hi Philipp,

Our team tried rerunning the command we have provided and here is the result:
https://chromium.googlesource.com/chromium/src/+log/4c0c9567aa5c87576b5811bc48f3e23e4e496aab..b4a25cc7cd8cd33d744329bbd59c1afc76cc60f3

we also tried your suggestion to narrow down bisect program run.  
cmd: python bisect-builds.py -a win64 -g 1375032 -b 1375048 --verify-range --use-local-cache
https://chromium.googlesource.com/chromium/src/+log/4c0c9567aa5c87576b5811bc48f3e23e4e496aab..b4a25cc7cd8cd33d744329bbd59c1afc76cc60f3
 
cmd: python bisect-builds.py -a win64 -g 1370689 -b 1375048 --verify-range --use-local-cache
https://chromium.googlesource.com/chromium/src/+log/d6a8de54aeb5eb5691a9c13b16f9610c124c67e5..b0d29d87381ae4b049a1d3c12a5cf74183e5d0b4

Asking again for help regarding assessing if there is something in the change logs that is related to the error we are encountering. Thank you! 

[Khristine Belandres]

Posting here comment from ticket https://issues.chromium.org/issues/391499612 to reproduce issue

================================

Here is a method to reproduce the issue:

1. Visit https://joji.blob.core.windows.net/test/chrome-132-xsl-issue/test.html.
2. Open the Developer Tools.
3. Click the Test button on the page.
4. In Chrome 131 (working case), "hello world" appears, indicating a successful XSL transformation.
5. In the latest Chrome 132, the transformation fails.

Details of the Reproducing HTML:

The test HTML contains a simple iframe. When clicking the button, the iframe loads a test.xml file with the following content:

<?xml version='1.0' encoding='ISO-8859-1'?><?xml-stylesheet type="text/xsl" href="./reqLine.xsl"?> <RQStuff> <static>./testu1LINE.xml</static> </RQStuff>

The test.xml file references reqLine.xsl and testu1LINE.xml.

Characteristics of testu1LINE.xml in this issue:

1. Its XML declaration includes encoding='ISO-8859-1'.
2. There are 15206 spaces between the XML declaration <?xml version='1.0' encoding='ISO-8859-1'?> and the root node <LineEntryScreen>, and 11502 spaces between the closing tag </LineEntryScreen> and the end of the file.

Workarounds:

Through testing, removing either of the following resolves the issue:

• The encoding='ISO-8859-1' declaration from the XML header.
• The excessive spaces in the file.

I made another interesting discovery:

When I launch a fresh Chrome user profile using the command:

chrome --user-data-dir=c:\temp\newuser --no-first-run https://joji.blob.core.windows.net/test/chrome-132-xsl-issue/test.html

Even on the latest Chrome 132, the issue does not occur initially.

However, after about 10 seconds, if I refresh the page and retry, the issue can be reproduced.

[Khristine Belandres]

Hello Jayson,

We have been testing against other channels Beta, Dev, and Canary, and we are still encountering the issue.

You have idea how the culprit issue could be looked into further by Chrome?

[Justin Besmano]

One other issue encountered by our team was special accent characters is not displaying properly after the chrome update.

Attaching bisect-build results, for reference, when we tried to replicate the issue on our end.

without range: https://chromium.googlesource.com/chromium/src/+log/2514f483b117fae2ac9c1afd7933099a3ea6b648..122106a674906b2a4cc875b11fa57be14bb4730d
range -g 1374476 -b 1374483: https://chromium.googlesource.com/chromium/src/+log/2514f483b117fae2ac9c1afd7933099a3ea6b648..122106a674906b2a4cc875b11fa57be14bb4730d

Thanks, 

[Jayson Adams]

One other issue encountered by our team was special accent characters is not displaying properly after the chrome update.

Better to file a bug (with detailed information about the issue, screenshots, etc.) than to post to the mailing list.